Accepting Bitcoin payments on my website using bitcoind? Many questions... no apparent answers I am trying to design a system that lets me accept Bitcoins on my website. I would like to use bitcoind, or bitcoinj. However, I have many questions regarding this setup.

FYI, I already read similar questions on this website and haven't gotten my answer.

Bitcoinj:

Seems tricky. I wasn't able to find any example code that works for me. Don't take it as a sign of incompetence or laziness on my end. The examples on their site didn't work properly because they renamed many of their classes and I can't get it to work. If you have a piece of code working with the latest version, please point me to that direction.

Bitcoind:

How many addresses can bitcoind reasonably manage? Is it a good idea to create tons of addresses and have bitcoind watch all of them?
How often should I 'flush' the wallet? It doesn't make sense to me to keep the same wallet all the time since that file will grow huge in time.
I am planning on doing the following:

1) User generates the address on my website, sends BTC.

2) I start polling 'listunspent' every X minutes. When I see that the TX got N confirmations, I send the money to the cold storage. I also put money down on the sender's account on my website.

3) Now how do I get rid of this address? It sounds like these addresses will accumulate and break bitcoind after some point.

I have read a lot about this but nobody explains this aspect. They just revolve around the problem.

Actually Ive done this.

What I would say is that if you are planning to it your self it requires some amount of time and expertise if you really want to implement a custom solution that can integrate with your web platform. I did some research and in the end this is how I did it.

I use Bitcoind

It runs on a private server well away from the web server.
On the private server there are several encrypted wallets running on different ports under different user accounts each of them runs the RPC deamon that only responds to ssl from the local host.

Users have an account on on the web application, when they are created they are assigned to one of the private wallets and given an account in that wallet.

The web application sends an RPC request for getaddress  using a message queue that a process on the private server listens to. This issues a new address for payment and puts it in the web applications database.

When we want to accept payment we display the new address to the user on the web page

On the private server a deamon runs every minute or so that calls getreceivedbyaddress  -minconf with the addresses we have displayed to users to receive payment.

when it sees a new payment it updates the webservers database with the record of the payment.

To make it more complicated but secure the communication is also encrypted and the details of the transaction signed using a shared secret between the web server and the wallet daemon process. So for example the web application wont regard the payment as accepted until it sees a signed transaction in its database and the deamon wont put one there until it has seen the minimum number of transactions confirmations on the network.

It took me a couple of days to implement but I had quite a big head start.
The easiest way is to go with one of the payment vendors who have done the hard work for you unless you plan on becoming one of them.

There are several other gotyas you have to be aware of.. for example
Keeping a secure backup of the remote wallets
Keeping the address pool in the remote wallets primed and making sure you have backed up the wallet after priming it.
Storing the wallet pass-phrases so you don't lock your self out
having a way to change them..

What I do is have a multi signature approach where half the wallet phrase is sotred in the daemon binary so the developer could get hold of it.. The other half entered at run time by the support guy. Neither of them would have the full pass phrase so cant steel the wallet and run away with it easily.

Regarding the problem of creating too many addresses and not being able to remove them.
At them moment this is not a problem for us as our solution will scale as we get more users we can create more wallets.

As for cold storage I'm not completely convinced this offers us any more security than we have now with out giving us more problems associated with managing the cold part of the storage. At the moment its a numbers game. where by if we only have $5000 in a wallet its probably not worth it. If we have $3 million in a wallet then we would firstly be ecstatic our business was that successful, Then probably invest in a more secure private data center some brand new servers and some very clever security people


Does getreceivedbyaddress or listreceivedbyaddress or listunspent shows pay to pubkey and bare mutlisig transactions? Couldn’t find the answer inside the source code.
If I receive a pay to pubkey transaction to the pubkey of a 1r address, will it shows up using getreceivedbyaddress or listreceivedbyaddress or listunspent? Or will it ignore the coins received that way.
The same question apply when 1-of-n bare multisig.

In the Bitcoin Core wallet, it depends:

For P2PK outputs to a public key that's in your wallet, yes for current wallet versions, but this won't be the case for the new "descriptor" wallets (unless explicitly imported).
For bare multisig, only when explicitly imported. Before PR 13002, bare N-of-N multisig was automatically treated as incoming payment (in case you had all N private keys). Since that PR you need to explicitly import these scripts to watch them.

For other wallet software, things may be different.
In general, you cannot assume that anyone will ever treat an incoming transaction as a valid payment, unless it was sent to an exact address they gave you (or you have some other explicit arrangement). Which scripts/addresses a user considers "theirs" is up to them, depends heavily on the software they use, and not something you can infer.


Problems loading blockchain from existing folder I once saved the "blocks" folder + the "index" folder of the Bitcoin wallet.

Now on another PC I thought I could load the chain that way by copy pasting these folders in Appdata. Wasn't very smart not to copy directly the whole file folder.

So in my situation what else do I need exactly to properly launch the wallet with a full blockchain ? Please help I don't want to download the chain again...

I get this error:

2017-02-01 02:56:15 ERROR: ReadBlockFromDisk(CBlock&, CBlockIndex*): GetHash() doesn't match index for CBlockIndex(pprev=0xd4ba3c0, nHeight=299478, merkle=4f27a1a8c5f19894e7012ce4ea4f83eba0ea846af888749980d855e5d7179e46, hashBlock=00000000000000001e66b8d27a6bcff234f06d502a01aa23fd4be311d8b2dbf2) at CBlockDiskPos(nFile=138, nPos=8)

As far as I am aware, you will also need the chainstate folder in order to properly run from a backup. Other files/folders are not strictly needed to restart your daemon. More information concerning specific folders can be found here: https://en.bitcoin.it/wiki/Data_directory

If all else fails start the process with -reindex and let it run - it "only" takes 24-48 hours depending on your bandwidth. Even though I know you don't want that!


Do pool servers communicate with bitcoind, and in what capacity? I'm trying to understand how the whole process flows. Here's how I currently understand it working.

  Mining client -> Pool server -> Bitcoind

  getwork:

  Mining client calls getwork from Pool server, and it in turn calls getwork (or something else?) from Bitcoind.

  stratum:

  Mining client ingages the Pool server using the stratum protocol, and the Pool server calls getwork (or something else?) from
  Bitcoind.

  getblocktemplate:

  Mining client calls getblocktemplate, and the Pool server calls getblocktemplate from Bitcoind.

And I understand that the pool server does more than just relay information, but I wanted to keep it simple. I just want to get a grasp of how it all flows together, and what calls it makes.

Any help is greatly appreciated!

getwork is for all intents, completely deprecated due to it's inefficiency. At this point a single ASIC device can completely swamp a bitcoind with requests as they're able to exhaust the 32bit nonce in a fraction of a second. The situation is severe enough that pools like BTC Guild have extraordinary large (6%+) fees on clients using getwork in order to get them to switch to more efficient methods.

Internally, pools like Eloipool use getblocktemplate to generate work for the clients, and then use stratum or getblocktemplate to communicate with the workers depending on the request type they make. getwork is not involved at any stage. In fact, it's currently pegged for complete removal at some point.


Why does txID generation consider signatures? I've been reading a lot about transaction malleability, and noticed that the only way to achieve it is by altering the transaction signature/s.

Why does the protocol even consider the signature in the payload for SHA256?
The protocol should only consider inputs and outputs as they are, ignore the signatures. txID should only be altered by altering inputs or outputs, thats it. If anybody would like to alter any input or output to change the txID, he'll need to change signatures as well.

In other words, if you don't consider signatures while generating the txID, transaction malleability would be impossible.

Please, let me know if I'm missing something here.

If the signature was not part of the transaction protected by the hash, then you could have two different transactions, one valid and one invalid, with the same transaction ID. The primary purpose of the transaction ID is to permit agreement on whether a transaction is valid or not. So excluding the signatures from the hash would make transaction IDs unsuitable for their primary purpose.

One proposal for dealing with malleability attacks it to have a second transaction ID just for the purpose of defeating such attacks. This transaction ID wouldn't cover the signatures. But it wouldn't be suitable for checking transaction validity, forcing a system in which there are two types of transaction identifiers.


Pybitcointools python 3.5 support I am trying to run Vitalik Buterin's python bitcoin wrapper.

I installed it from PyPi (pip install pybitcointools ).

When I try to run:

import bitcoin

I get the following error:

  ImportError                               Traceback (most recent call
  last)  in ()
  ----> 1 import bitcoin

  ImportError: No module named 'bitcoin'

I will appreciate any pointers on this

try:

import pybitcointools

that fix my problem


How does intial block download work at P2P layer? A simple DOS attack while IBD could be as follows:

The fresh client is currently downloading block 100.
Then it is offered 10 blocks at height 101, each claiming they are the heaviest chain
9 out of 10 alternatives are
    with fake PoW but still the client will waste time in getting the
    entire block and validating their PoW.

How does the current implementation of P2P protocol in bitcoin-core handle this sort of DoS attack?

Bitcoin Core does headers first sync so it downloads the headers first and partially validates them before downloading the blocks. So if a malicious node sends headers with invalid PoW's, the syncing node will disconnect from it and sync headers off of another node. If the it receives multiple headers for the same block height, that node will be considered to be misbehaving and stop syncing headers from it.


What does the main_chain value returned by blockchain.info mean? What does it mean that for bitcoin block to be on the Main Chain? What other chains are there? Is this as opposed to testnet?

This is regarding the main_chain value in the blockchain.info api here:  https://blockchain.info/api/blockchain_api

If a block is part of the main chain, that means that the tip of the blockchain is a descendant of that block.

If a block is not part of the main chain, that means there is a longer chain of blocks that does not include this one. These are called orphaned blocks or invalid chains.

If a block is in the main chain, its parent is automatically in the main chain too.

In the above figure, the black boxes are the main chain. The grey blocks are invalid chains. The green box is the genesis block.


Does sending non-ripple-money through Ripple require two people to be connected through a web of trust? Say we have two people - first one puts some money into their Ripple address through a use of a gateway. They are not trusting anyone on the network, but need to send their money to a second party that may or may not be in a similar situation. How would Ripple transfer the money from the first individual to the other?

You can't get money on the Ripple network unless you trust someone to owe it to you. To have $100 in the Ripple network, someone must owe you that $100. If you haven't chosen to trust anyone to owe you money, nobody can owe you $100 and thus you can't have any money.

So when you give money to a gateway, you must allow them to pay you in IOUs. And if someone is expecting you to pay them money, they must allow someone to owe them that money or it's impossible for you to pay them. Now if you've both chosen to trust the same gateway, it's simple -- you just hand them the IOUs you just bought.

If you trust different gateways, then a path between those two gateways must be found. With luck, there will be someone who holds IOUs from both gateways and doesn't particularly care which IOUs they hold. So you can use them to "move" your IOUs from one gateway to another.


Can you list receiving addresses in bitcoin-cli? In bitcoin-qt, there are interfaces for seeing "receiving addresses" which have been generated in the past. I don't see any way to do that in bitcoin-cli.

Yes, you can do it.

bitcoin-cli listreceivedbyaddress 1 true

I had to read the argument documentation. Thanks Sven Williamson.


What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network? There has been a lot of discussion and articles around how the implementation of AMP is going to benefit the routing capabilities of Lightning Network. What is the exact issue in the current implementation of Lightning that AMP is solving? How does AMP really work? and how is it going to be implemented?

The Current Problem

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

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

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

The Solution

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

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

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

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

Implementation

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

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

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

Future Releases

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

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

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


What is the Bitcoin network? This is a beginners question related to bitcoin.
As bitcoin is a system of distributed bitcoin users, and a transaction is being sent to 'all' of them - well, what is that network? What IP adresses? Is there a bitcoin databank of bitcoin users? Is there an initial list of some users? How does this 'network' work?

A node is a "point" that relays new transactions and blocks.
For example, if a make a transaction from the GreenWallet app, the GreenWallet app will send the transaction to GreenWallet's API. The node(s) GreenWallet runs will broadcast that transaction. The rest of the nodes will relay those new transactions to each other.
Only some of those nodes are also miners. They listen for

new transactions, so that they could include those transactions in their next blocks.
new blocks, since every block must reference the hash of the previous block.

An Antminer, which is an ASIC machine, is not a node. It specializes in doing the work given to it. A mining node, today, refers to a pool operator's node.
Additionally, pool operator nodes utilize low-latency block distribution routes such as the Falcon Network. This is to ensure that all miners have access to the latest block's hash. If two blocks reference the same previous block, one of them will be orphaned, which means the longest chain will be following the other block.
Software such as the BRD app or Bitcoin Core can act as nodes and they can directly push their transactions. The difference is that Bitcoin Core has the ability to store the whole blockchain, which most of Bitcoin Core instances do. This kind of node is said to be a full node. Bitcoin.org defines a full node as a "fully validating client". The opposite is a pruned node, which discards irrelevant data.
"User" is not defined for Bitcoin. There are miners, which make new blocks, nodes, which act as transparent connectors between nodes and miners, and wallet clients, which just keep track of relevant balances and transactions. Note that bitcoins aren't located in addresses. Transaction outputs are called unspent outputs, which may be spent with the corresponding private key and the public key of the address.


Is there an open source Bitcoin exchange? I just found this project, which is described a.t.m as a learning project.

Is there a more serious, open source Bitcoin exchange? I'm aware exchanging BTC for fiat money can be quite complex, and might not fit an open source model, but an exchange specializing in crypto-currencies shouldn't be that complicated to setup, so I think there is room for an open source one.

Intersango is an open source exchange that is used at intersango.com, which is an exchange operated by The Bitcoin Consultancy. The open source project that can be found here is released under the GNU Affero General Public License.

For more info on how to set it up, see this post on the bitcointalk forums: Intersango HOWTO - Build your own Bitcoin Exchange Web Site!


Does Bitcoin script support nested IFs (OP_IF or OP_NOTIF inside one another)? For example can we convert the following code to a script?

if(bool_1)
{
    FOO1();
    if(!bool_2)
    {
        FOO2();
    }
    else
    {
        BAR1();
        if(bool_3)
        {
            BAR2();
        }
        BAR3();
    }
}
else
{
    FOOBAR();
}

<push> <push> <push> OP_IF OP_FOO1 OP_NOTIF OP_FOO2 OP_ELSE OP_BAR1 OP_IF OP_BAR2 OP_ENDIF OP_BAR3 OP_ENDIF OP_FOOBAR OP_ENDIF(correct?)

If yes then:
1. Is there any limit on how deep a nested IFs can go?
2. Is there any examples (raw bytes/hex) I could look at?

Do bitcoin scripts support nested ifs (OP_IF OP_NOTIF inside one another)?

Yes, Bitcoin support nested IF/ELSE. In fact we use the nested IFs in Lightning Network all the time when adding HTLCs to forward a payment.

  Is there any limit on how deep a nested if can go?

There is no explicit rules dictating how far deep the nested IFs can go but there are some constrains on the script itself:

Maximum number of bytes pushable to the stack should be less than 520 bytes
Maximum operations per script is limited to 201
Maximum size of the script is 10,000 bytes
Maximum number of values on script interpreter stack is 1,000 bytes

  Is there any examples (raw bytes/hex) I could look at?

As I mentioned earlier, we use nested IFs all the time while adding HTLCs in the Lightning Network implementation. Below is an output script of offered HTLC outputs for a peer.

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF


Extracting information from utxo for offline processing I would like to extract as much information about the utxo set (all unspent transactions) up to a given block height, including value and scriptpubkey.

This information is meant to be inserted into a database and processed offline for some statistical analysis. I have been looking at multiple alternatives including bitcoind, bitcoin-ruby, libbitcoin and others, but cant figure out how to do this. Perhaps my programming skills arent that hot.

Hoping someone can help me out. Thanks!

Blocks and transactions have very simple structure. It is very easy to parse them in any language. This is a piece of my code (it definetely works). You may write something similar

#include <QTimer>
#include <QFile>

#include "BlockChain.h"
#include "Util.h"
#include "Chainer.h"
#include "Target.h"

BlockChain::BlockChain ( QObject* parent ) : QFile ( parent ), blkFile ( 0 )
{
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}
//--------------------------------------------------------------
void BlockChain::start ( )
{
  setFileName ( blkFileName ( blkFile++ ) );
  if ( !open ( QIODevice::ReadOnly ) )
  {
    _trace ( QString ( "cant open [%1]" ).arg ( fileName ( ) ) );
    getParent ( ).block ( QByteArray ( ), 1 ); // end-of-blockchain signal
    deleteLater ( );
  }
  else
  {
    _trace ( QString ( "processing [%1]" ).arg ( fileName ( ) ) );
    QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
  }
}
//--------------------------------------------------------------
void BlockChain::next ( )
{
  bool lock ( true );
  if ( pos ( ) < size ( ) )
  {
    quint32 magic;
    quint32 size ( read ( (char*)&magic, 4 ) );
    xassert ( ( ( magic == MAGIC_ID ) || !magic ) && ( size == 4 ) );
    if ( magic )
    {
      read ( (char*)&size, 4 );
      xassert ( size > HEADER_SIZE && size <= MAX_BLOCK_SIZE );
      getParent ( ).block ( read ( size ), 0 );          // block signal
      QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
      return;
    }
    else
      lock = false;
  }
  close ( );
  getParent ( ).doneFile ( lock, blkFile - 1 );       // notification
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) ); // next blk file
}
//--------------------------------------------------------------
const QString BlockChain::blkFileName ( const int i )
{
  return
    ( i < 10 ) ? QString ( DATA_ROOT "\\blk0000%1.dat" ).arg ( i ) :
    ( i < 100 ) ? QString ( DATA_ROOT "\\blk000%1.dat" ).arg ( i ) :
    ( i < 1000 ) ? QString ( DATA_ROOT "\\blk00%1.dat" ).arg ( i ) :
    ( i < 10000 ) ? QString ( DATA_ROOT "\\blk0%1.dat" ).arg ( i ) :
    QString ( DATA_ROOT "\\blk%1.dat" ).arg ( i );
}


Why do we need a "routing" process in Lightning Network? If I am wrong, please correct me.

If we simplify Lightning Network, it seems to work similar to this simple unidirectional payment channel between two parties (although, Lightning Network is a bidirectional).

So we may simplify the process of a payment between two parties in Lightning Network as follows:

(1) the sender and recipient just need to create a channel and deploy the contract and then the sender puts the recipient's address in the contract as recipient.

(2) Then any agreed number of  off-chain transactions will be done between sender and recipient such that the sender's address for each mico-payment will be verified by recipient.

(3) Eventually, a settlement will be done via an on-chain transaction, by which the recipient will receive the total amount the contract.

In a first view, it seems no need for "routing" process.

So, can we now ask that why do we need a routing process for performing a payment in Lightning Network?

P.S. I refer you to the Lightning Network website, where it's mentioned that:

  "By creating a network of these two-party ledger entries, it is
  possible to find a path across the network similar to routing packets
  on the internet."

Note: The payment channels are composable, meaning that  If A and B have a payment channel, and B and C have another, then A can pay C through B. But the matter is that there is a fee incentive for intermediaries. Now the question is which one is more affordable?

(1) Doing like above approach?

Or

(2) A and C create another channel between themselves without paying to B and without need for routing ?

So, the answer of necessity of need for a routing process in Lightning Network is dependent on affordability of paying to one or multiple intermediaries instead of paying for a new direct channel without intermediary?

Even though Pieter Wuille has sad most of what was needed in the comments I will summarize this as an answer.

Technically you could open a payment channel with every other person instead of creating a network with the ability to route. The drawbacks are that your total bitcoin amount has to be distributed over several channels and will be very small in each channel. Also creating channels with everyone would need way more on-chain transactions which would not directly help to reduce the load to the blockchain.

--> Routing is needed to really reduce the amount of onchain transactions needed and to have higher liquidity per channel available.


Bitcoin cash command line tools? How can I use Bitcoin cash from the command line? In my understanding, even standard bitcoind and bitcoin-cli should work fine with it because the only blockchain was changed.

But may be there are any special tools/flags? Can you give some dead simple example, e.g. adding the new address to account and checking it's balance? With Bitcoin and bitcoind it can be done with 3 lines of code:

$ bitcoind -daemon
Bitcoin server starting
$ bitcoin-cli getnewaddress pavlovdog
1PB8NHbSG3CgvpzSMrvdeeAKaojZBXrwb # I've sent to this address 0.0001 BTC
$ bitcoin-cli getbalance pavlovdog
0.00010000

Thanks in advance!

You want to download the Bitcoin ABC client, then move your existing bitcoin directory (~/.bitcoin in Linux) or understand that you are going to modify that bitcoin data to go down the Bitcoin Cash fork.

You can use those same CLI coins just want to use the ABC client or any other client on the Bitcoin Cash side of the split.


Without knowing private public key any one can withdraw btc from address. Is it possible?' Actually I am using blockcypher API for creating address of btc and storing all records in my database with private and public key of individual address and assign that to particular users.
But few days before from my users address balance will become zero.Amount transfer into some other address.How is this possible?
Please help me out from this Its very risky.

Thanks in advance.

Regarding your title, without knowing the private key, no one can withdraw your BTC, that's for sure.

First of all, I would argue it's a bad idea to use a third-party online service to generate and manage your keys. I went to check the blockcypher site, it seemed legit. Did you spend your coins? If so, the money may be moved to a new address because the change address is different. They've said in the docs,

  BlockCypher will set the change address to the first transaction input/address listed in the transaction. To redirect this default behavior, you can set an optional change_address field within the TX request object.


Who pays me when pool mining? When I pool mine, do my payments come from the pool operator's personal account? From the pool's wallet? Or from somewhere else?

When using P2Pool, the payments appear in bitcoin-qt as though I had mined the block myself.

Broadly speaking, there are two ways of paying pool miners. The first way is to have a wallet and send payments to miners through that when they ask for them.

The second way, which both eligius.st and p2pool use, is to keep track of how many shares people get, and set the coinbase transaction to pay the block reward directly to them once a block is found. This has the advantage that you never have any Bitcoins to steal on your pool server.


Does number of inputs or outputs affect bitcoin transaction fee? I would like to know how inputs and outputs affects my bitcoin transaction fee using legacy address, and how using a segwit address will decrease the same  transaction?

and how they will be calculated?
if input and outputs affects how can avoid that, apart of segwit address method?

thanks a lot.

Format for 1 input 2 outputs (1 to receiver, 1 change to owner). Normal non-seg transaction

P2SH    73 bytes(input) 32x2 (output)

P2PKH  about the same as P2SH

To reduce fees reduce

a) no of inputs.

b) Use exact match (with no change output) if possible.

c) when fee is low, use more inputs or consolidate your input to fewer UTXO.(reduction of input for your future tx).

I think fee reduction increases a lot when you use multi-sig using seg-wit.

Output format 2of3 multisignature
      Input size    Out size

P2SH    297 32

P2SH-P2WSH  140 32  Wrapped Segwit

P2WSH   105 43 Native Segwitness

P2TR    58* 43 Pay to Taproot

P2PKH   148 34

means the recovery is more expensive.

To be actually sure of saving then you may want to go through the exercise of manually decoding every different type of bitcoin TX with various no of input and output.

(up to byte level where U can actually count).


Default http port for lcoin? What is the default http port that lcoin listens on? bcoin listens on port 18332 for http by default, however lcoin documentation links only point to bcoin doc links

lcoin listens on port 19336 by default, however you can set another port by using the --http-port=<your port> flag when starting the node


Request blockchain for transactions I have installed bitcoin-qt, so I maintain the blockchain locally. I have a list with transaction hashes strings (i.e f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6) and I want to request information about those trasactions (input/ouput public keys, value etc).

I know that I can do it with blockchain.info api, but the problem is that there is a huge amount of transactions, and the avereage time of a single transaction is 0.3 secs. (So for millions of transactions there must be days)
I have also tried bitcointools but this project is becoming obsolete with recent versions of Bitcoin-Qt/bitcoind.

Any suggestions so as to make the whole procedure more efficiently?

Not sure what exactly you need to do once you have found your information as that can be a big drive in what tool you use as well. However you can use bitcoind api which is packaged with bitcoin-qt to get all infromation about a transaction using this command.

gettransaction <txid>

It will return to you all the infromation about that transaction, I would use some other tool build on top of it such as a php api or whatever your favorite language is. Here is one that I made to interact with it via PHP https://github.com/michaeljs1990/Bitcoin-PHP-API .

More about the bitcoind API can be found at https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


Is there a command I can type into Bitcoin-Qt to see the total number of bitcoins that have been created? I know how to obtain this information from other means, I specifically want to know if it's possible for me to obtain this information using the Bitcoin-Qt client alone.

I am running it on Windows Vista and I don't have a miner set up.

Thanks.

You can calculate the total amount of when you know the last block in the block chain. You can check the number of block by holding your mouse on the icon in the lower right corner of the Bitcoin-Qt client.

Then you will need to use this table to calculate the total amount of bitcoins there exist. This table just lists up the block rewards, which halves every 210,000 blocks and starts at 50 BTC.

Currently you can easily add the 10,500,000 BTC from the first 210,000 blocks with 25 times the current block count minus 210,000.

If you want to have an implementation that you can use forever, it would look like this (I used Python):

def total_bitcoins(current_block_count):
    count = current_block_count
    reward = 5000000000 # satoshi
    total = 0
    while count > 0:
        total += min(count, 210000) * reward
        count -= 210000
        reward /= 2
    return total / 100000000.0

Note that this process limits the total amount of bitcoins that will ever be created to 20,999,999.9769.


How can i get balance of bitcoin address not exist in my wallet? How can i get balance of bitcoin address not exist in my wallet ?

I try to use bitcoin-Abe but it is complicated and take seral days to full database with blockchain.

Is there exists other tools like bitcoin-Abe but easy and fast to parse blockchain, i want from parse blcokchain to get balance and transactions of bitcoin address ?

Does armory contain any facility to parse blockchain or get balance of any address and it's transactions ?

If you have bitcoind running, you can get balance without using bitcoin-abe.
Basically you need addrindex enabled in bitcoin. A simple script can get all transactions of a given address and then calculate the balance. You can use https://github.com/cnu1439/blockchain-utils


1 of n Multisig Scriptless Scripts? I know MuSig makes n of n multisig  scriptless. However, can we also aggregate multiple internal public keys in one public key, and unlock funds using either one of the internal public keys?

MuSig does not support m-of-n multisig, so you should use a threshold signature scheme like this:
http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps


How are transaction IDs generated and how are they then changed by transaction malleability? How are the transaction IDs generated for a Bitcoin transaction? How can the transaction ID change due to a transaction malleability attack?

The transaction ID is the SHA256d(signedTransaction) = SHA256(SHA256(signedTransaction)). Sha256d is SHA256 applied two times.

Example:
Let us consider the transaction with ID 844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109. The hex encoding of this transaction is:

02000000019e8cc9f5c7e16bc11e6f4050fbdf925e5ea9e0d3c8b430bce4afc61fa7675c53000000006b483045022100efc6e04a4735465257c4f0ff51f9015c3806daebb390ceb1ae18402794a3192c02204616b6cd7c86321d896270d2758db2d245f0c14d60693711c1e891fa2ea5c1010121036a9946621a6428c3719cd992f32c5ebf1fec1c403e2f7796301fc000473bf2b6ffffffff03802b21000000000017a914f896d5607bc2b01309019104d9dd33fa76d79f538751cfa600000000001976a9145a45d570db268e085de17cb5b53d5dba5eeb855d88ac63890100000000001976a9148ae4ce7cbda181e6c2635d15e518dafbbabd5caa88ac00000000

You can check that the SHA256d for this signedTransaction is 091194d5da982a2da39776b76b2ac7cb7b2fdf03e2fe1bb66ec25b06ca004c84 on this page:
http://extranet.cryptomathic.com/hashcalc/index (remember to tick the 'Enter as hex' box) by flipping the endianness (Bitcoin uses small-endian representation of hex numbers/byte arrays), you get the expected result:

844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109

Transaction malleability means that you can change the signedTransaction without invalidating it. So someone else has provided the signature but you can change the signed transaction in some way without invalidating the provided signature.

A Bitcoin transaction consists of different fields such as inputs, output amounts, output destinations etc. One of the fields is called scriptSig and this is where the signature goes.

It is possible to change the scriptSig field without invalidating the signature. The scriptSig field consists of instructions (opcodes) where a signature is considered valid if the execution of the scriptSig field followed by the execution of the scriptPubKey field (another field consisting opcodes) leaves the number 1 on top of the stack. The virtual machine that executes the opcodes is a stack machine.

For example you can add the op code OP_NOP (which does nothing) in front of the rest of the scriptSig without invalidating the signature. The signed transaction may still be picked up by miners but the transaction ID (once it is included on the blockchain) will be different than what the signer expects.

Segregated witness transactions solve this problem by removing the signature from the scriptSig field into a new field called the witness field and it also prevents any additional data from entering the scriptSig field thus preventing the malleability. The TXID of a segwit transaction is calculated the same way but it does not include the new field, the witness.


When building bitcoind, I receive error "headers.h:36:20: fatal error: db_cxx.h: No such file or directory" When building bitcoind on LinuxCoin (Debian based), I receive this error

  "headers.h:36:20: fatal error: db_cxx.h: No such file or directory"

following the instructions at https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.txt

I believe the error is caused by the package "libdb4.8++-dev" being non-existant for the distro, as when attempting to "apt-get install" that, I get:

  Package libdb4.8++-dev is not available, but is referred to by another package.
  This may mean that the package is missing, has been obsoleted, or
  is only available from another source

  E: Package 'libdb4.8++-dev' has no installation candidate

NOTE: libdb4.8-dev and all other dependencies are already installed.

It's probably a silly mistake on my part but any help is appreciated! Thanks.

I did the following command on Ubuntu and it worked.

sudo apt-get install libdb++-dev


Why is the obscured commitment number necessary in lightning commitment TX's? The obscured commitment number for each commitment transaction is the lower 48 bits of:

SHA256(payment_basepoint from open_channel || payment_basepoint from accept_channel)

It is encoded in the lock time and sequence fields (24bits each) of the commitment transaction. I don't understand why it is necessary, the BOLT rfc reads:

  This obscures the number of commitments made on the channel in the
  case of unilateral close, yet still provides a useful index for both
  nodes (who know the payment_basepoints) to quickly find a revoked
  commitment transaction.

Why doesn't the TXID of the commitment TX suffice as lookup index key?

Looking at the c-lightning code I find this call:

    txs[0] = commit_tx(ctx, &channel->funding_txid,
               channel->funding_txout,
               channel->funding_msat / 1000,
               channel->funder,
               channel->config[!side].to_self_delay,
               &keyset,
               channel->view[side].feerate_per_kw,
               channel->config[side].dust_limit_satoshis,
               channel->view[side].owed_msat[side],
               channel->view[side].owed_msat[!side],
               committed,
               htlcmap,
               commitment_number ^ channel->commitment_number_obscurer,
               side);

in particular the following line:

commitment_number ^ channel->commitment_number_obscurer

Tracing down the commitment_number variable this suggests to me that it is really an integer. If you see how often in the code it has to validated that two commitment transactions are directly succeeding each other it makes sense to have an unobscured integer instead of a txid. Consider For example this code block:

    /* FIXME: Document this requirement in BOLT 2! */
    /* We can't send two commits in a row. */
    if (peer->revocations_received != peer->next_index[REMOTE] - 1) {
        assert(peer->revocations_received
               == peer->next_index[REMOTE] - 2);
        peer->commit_timer_attempts++;

It is obscured later since the information how many commitment tx existed should not be public. It is as far as I understand obscured with an OTP via XOR. The OTP is the one you mentioned above. The idea is to have an integer that can be used but obscure it when being sent to the blockchain. I did not find a position in the code where the obscured value is taken and processed to a clean value however.

I hope that helps (:


What will happen when nLockTime is used along with Counterparty transactions I heard that Counterparty cannot handle lock time, but I cannot understand why.

What will happen when we use nLockTime in a transaction which includes Counterparty transactions?

Disclosure: I work for Coinprism.

Counterparty uses the Blockchain for timestamping only. It doesn't use it as a ledger since it builds it's own "parallel" ledger.

As a result most advanced functionality of the Bitcoin ledger can't work on Counterparty:

nLockTime
SPV
Payment Channels and lightning networks (very important for scalability)
Unconfirmed transaction chaining (important for mobile payments and fast transaction processing)

If you want to be able to use all bitcoin features out of the box, you need to look at colored coins.


What is Ripple and how does it compare to Bitcoin? What is Ripple, and how does the system compare to Bitcoin?

This is answered in the official wiki:

  Like Bitcoin:

  ripple is a distributed peer-to-peer payment network
  ripple transactions are irreversible, sent over the Internet, and counterfeit proof
  ripple uses the same underlying cryptography as Bitcoin
  ripple has multi-signature support
  ripple has low to no transaction fees
  ripple servers can be run by anyone

  Unlike Bitcoin:

  ripple can send any currency
  ripple can automatically exchange currencies
  ripple transactions are fully confirmed in seconds
  ripple allows nicknames and gravatar icons for accounts
  ripple's reference client is a Firefox and Chrome add on
  ripple has no block chain download, clients are ready in seconds
  ripple has no mining or direct monetary reward for running a ripple server
  ripple has no currency risk as people can hold whatever fiat they want
  ripple solves the double spending problem with consensus instead of proof-of-work


Bitcoin transaction location I transferred my Bitcoin from my Exodus desktop wallet to another location. How can I find out, if possible, the exchange I sent it to that has my account? Is there any way to see the transaction code to find out what exchange my BTC is sitting on? Thanks.

Is there any way to see the transaction code to find out what exchange my BTC is sitting on?

You cannot identify an exchange from a transaction-ID.


How do wallet-sites generate large numbers of Bitcoin addresses? How do online Bitcoin wallet sites work? How can they have thousands of addresses laying around, or do they create them on the fly?  What sort of software is used to create all those Bitcoin addresses?  The reason I ask, is that I'm toying with an idea for a website that would require per-user Bitcoin addresses for payment.

At Justcoin.com, we've used a few different methods over the years:

Generate addresses using bitcoind, now called bitcoin core, when we need them. To avoid key loss in the case of storage failure, we use a large key pool. The command is simply getnewaddress.
Hierarchical deterministic wallets are much better and we use these for an increasing number of things. When using these for hot wallets, we import new private keys into our hot wallet before its ever used. That way we can still spend its inputs from bitcoind.


What mining performance can we roughly expect from the Intel SHA extensions of the upcoming Skylake processor architecture? Intel is scheduled to release their new x86 SkyLake microarchitecture in Q3 2015. Among other interesting features, it will introduce SHA extensions that will allow hardware acceleration of the Secure Hash Algorithm family, including SHA256 as used by Bitcoin.

In terms of SHA crunching speed, it is common lore that:

CPU < GPU < FPGA < ASIC

But where will these new extensions fit in this row? And how many orders of magnitude of speed difference can we expect them to have in comparison to the above hardware options?

Would it be useful to compare the extent to which Intel's existing AES extensions speed up AES functions compared to software-only AES?

EDIT: After reading up more on these kinds of special purpose CPU instructions, I realize they will most likely speed things up to be only several times faster than the software baseline; not several orders of magnitude faster, like ASICs, or even FPGAs are. Still, the question might be an interesting reference so I'll leave it.

Let's try to make a rough estimate.

Intel's article Intel SHA Extensions gives some details on these instructions as well as sample code.  The main feature is the sha256rnds2 instruction, which performs two rounds of SHA256, out of the 64 rounds that are needed to hash one 64-byte block.  A Bitcoin header is 80 bytes long, so that's 2 blocks, and because the mining algorithm is SHA256D, we need to do it twice.  So we need to execute sha256rnds2 128 times to perform one Bitcoin hash.

I'm no expert on modern CPU architectures, but I would suspect a complex instruction like this would take more than one clock cycle; nonetheless, let's generously suppose it doesn't.  Since each round depends on the outputs of the previous, these rounds probably have to be executed serially (on each core), so not much parallelization can be done.  But let's very generously assume there are resources that can be shared, so that the CPU can execute two sha256rnds2 instructions per clock cycle.  Let's also generously assume that all the ancillary code needed to set up for sha256rnds2 can be pipelined and doesn't require any additional clock cycles.  So it takes 64 clock cycles to perform one Bitcoin hash.

Now, how fast can we run the clock, and more importantly, how much power would be used?  Since power consumption is paramount, let's suppose that we would want to use a mobile CPU.  The Wikipedia article on Skylake suggests that the SKL-Y-1 model will have 2 cores and a thermal design power (TDP) of 4 W.  Let's assume the TDP represents the actual power consumption for our mining application, and furthermore let's neglect the power consumption of all other components of our machine (memory, power supply, etc).  There isn't any information given on clock speeds, but Intel's current Core M processors have a base clock speed of up to 1.2 GHz, with "turbo" up to 2.9 GHz.  Let's suppose this new Skylake device could run at 3 GHz sustained.

So our overall hash rate is

 3x10^9 clocks/sec / 64 clocks/hash * 2 cores =  93.75 MHash/sec

With a power consumption of 4 W, this gives an efficiency of 23.4 MHash/J.

By comparison, according to bitcoin.it's Mining hardware comparison, current ASIC miners are able to produce 1000-2000 MHash/J.

Conclusion:

  Even under extremely optimistic assumptions about the mining performance of the Skylake processors, modern ASIC devices are still 40-80 times more efficient.


What is ccache? When should I use it when building and reviewing Bitcoin Core PRs? What is ccache? Can you provide some guidance on when to use it for building Bitcoin Core PRs and how to use it?

The tool ccache helps store intermediate compilation results, so if you changes branches often, and rebuild, it can significantly speed up doing so.
To use it, you install ccache for your platform. That's it. The Bitcoin Core configure script will detect its presence, and use it automatically.


Bitcoin Cash sendrawtransaction error? I am trying to send a raw transaction from my Bitcoin ABC node.  It is not fully synced, but I have at least passed the point where I can see some of my transactions.  In trying to send a tx after creating it, I get the error:

16: mandatory-script-verify-flag-failed (Illegal use of SIGHASH_FORKID)

What is this, and how can I resolve it?

It looks like the error message for receiving a legacy transaction on a Bitcoin ABC node: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/174846aaaf564e64b6bd06d679996b52ba86ad53/src/validation.cpp#L1445

Speculation:
It seems plausible that Bitcoin ABC would create regular transactions before reaching the fork in order to retain compatibility with the Bitcoin network, but then recognizes them as being invalid to the upgraded network. (This is unverified speculation.)


The Bitcoin-Gold fork came before I expected.... can I still access my BTG? I transferred btc from gemini to a paper wallet around at 9:30pm Monday. Will I still be able to get my BTG? Where will they show up? I'm not sure when the "snapshot" was created.

According to this article, Bitcoin-Gold forked "at block 491,407 on the original blockchain".

If you look up your sending or receiving address in blockchain.info, and drill down into the transaction id, you should be able to find the block number that it was included in. This will allow you to work out whether your transaction was before or after the fork.

If you have access to the private key of an address where bitcoins were stored at the time of the fork, you should be able to get the BTG and the BTC as you have full control of them.

However, I believe Gemini is an exchange, so if you have bitcoins stored on the exchange at the time of the fork you'll be relying on them to give you any BTG you would otherwise have access to (assuming they don't give you access to the private key of the funds stored on the site... but exchanges usually don't).

Note that on 8th Oct 2017, Gemini announced on Twitter that they would allow users to withdraw Bitcoin-Cash, which was created as a fork of Bitcoin in a similar way to Bitcoin-Gold. Perhaps this is a good indication they will do the same for Bitcoin-Gold.


Why does my freshly installed lightningd not show funds that I transferred to it? I have a box with Ubuntu, bitcoin: fully indexed, and c-lightning.  I made several new addresses, and put money into one of them.  The money was transferred to it in block 655761.  I see the bech32 address when I run dev-listaddrs, it was sent to the right address.  Why would list funds show no outputs?

Clightning actually needs to scan all blocks to check for output's and Adresses it controls.
I assume most likely your c-lightning node is so fresh that it has not seen such a late block yet. Once your c Lightning node is up to date funds appear directly in listfunds once they are confirmed. So I guess you can do two things.

Check your log file and see how far c Lightning is with parsing through blocks
Wait until clightning is finished


I would like to dig into the open Taproot PR to understand it, test it and possibly even review it. Any advice or recommendations? I would like to dig into the open Taproot PR (PR #19953) to understand it, test it and possibly even review it. Any advice or recommendations?

Previous Bitcoin Core PR review club sessions
A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also links to the previous review club sessions on the Taproot PR on that page.
Build the PR
When reviewing a PR it is always a good idea to build the PR. For simplified guidance on building a PR see this StackExchange question. For more detailed guidance see this resource from Jon Atack.
Obviously the fork of Bitcoin Core you will want to clone is sipa's (Pieter Wuille's) and the branch you will want to check out is taproot.
There is no GUI or wallet support in this Taproot PR so you will want to use the following flags when configuring to save time.
./configure --without-gui --disable-wallet

Understand what the PR does (and what it doesn't)
On the PR Pieter Wuille states:

No signing or wallet support of any kind is included, as testing is done entirely through the Python test framework.

This is pretty limited scope. All signing and validation of (Schnorr) signatures is already handled by the libsecp256k1 library which has its own separate repo. But what Pieter is saying here is that with the current Taproot branch you can't create a Taproot (pay-to-taproot or P2TR) address or Taproot spend from your Bitcoin Core wallet or using bitcoin-cli. The only way you can create Taproot transactions is using the Python code in the functional test framework. So if you know some Python you can adjust the Python code to create different Taproot transactions but other than that you can't create Taproot UTXOs or spend from them.
Once Taproot transactions are created from the Python functional test framework this PR branch will allow you to validate Taproot spends with the C++ validation code.
Functional tests
Given the only Taproot transactions that are validated by your Bitcoin Core full node are coming from the functional test framework it is a good idea to start your code review there. Some existing functional tests are edited in this PR but there is a new functional test added called feature_taproot.py. This test generates random Taproot transactions and verifies they are accepted into the mempool (when appropriate) and accepted (when appropriate) into Python-constructed blocks.
You can run this new functional test directly by running:
test/functional/feature_taproot.py

After a few minutes this test will very likely pass. So here is where you can be creative in making changes to the test or the C++ code it is testing before running the test again to see what you need to do to make this test fail.
What to avoid
There are a few things to avoid on this PR. It is still possible that there is a conceptual problem with the Taproot design but at this stage it is unlikely. There was an in depth discussion of the evolution of the conceptual design of Taproot at this Socratic Seminar at London BitDevs covering years of discussions. I would recommend watching that or reading the transcript of that if you think you have discovered a conceptual problem. Alternatively, you are free to ask questions on the ##taproot-bip-review channel on IRC.
Another thing to avoid on this PR is discussion of activation (or deployment). This PR completely avoids any decision on activation method and so there should be no discussion of activation on this PR. If you look at the commit on Activate Taproot/Tapscript on regtest (BIP 341, BIP 342) there is a deployment date set of January 1 2008 for regtest but other than that no activation or deployment parameters are set. If you would like to discuss activation there is another IRC channel ##taproot-activation for that purpose.
// Deployment of Taproot (BIPs 340-342)
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].bit = 2;
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = 1199145601; // January 1, 2008
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nTimeout = 1230767999; // December 31, 2008

The PR is at a reasonably advanced stage and what it is really seeking is code review, testing and (maybe!) additional tests.
For guidance on debugging Taproot functional tests see this other StackExchange question.


How is the previous transaction found efficiently? When a new block is being created, all the transactions must be verified. In order to do that, the outputs of the previous transaction must be found in the blockchain.

But the new transaction only refers to the previous transaction by a hash. How is that transaction located without searching the whole blockchain?

Bitcoin clients maintain a list of the current unspent outputs in a hash table.


Programming and the ECDSA equation I've been implementing point addition into a c++ program I've written but I don't see how this can be done right.  When I do slope = (y1 - y2)/(x1 - x2) I get a freaking decimal, which doesn't produce the proper points when applied to the other parts of the equation due to  it not retaining its fractional qualities.  Anyone have any ideas how how to get past that?

Point Addition being defined by the following equation:

slope = (y1 - y2) / (x1 - x2)

xsum = slope ^ 2 - (x1 + x2)

ysum = slope * (x1 - xsum) - y1

Whereby Private Address x02 with x,y coordinates respectively:

89565891926547004231252920425935692360644145829622209833684329913297188986597
12158399299693830322967808612713398636155367887041628176798871954788371653930

with the Point Addition of Private Address x01 with x,y coordinates respectively:

55066263022277343669578718895168534326250603453777594175500187360389116729240
32670510020758816978083085130507043184471273380659243275938904335757337482424

applied to the above equation produce the result of Private Address x03 with x,y coordinates respectively:

112711660439710606056748659173929673102114977341539408544630613555209775888121
25583027980570883691656905877401976406448868254816295069919888960541586679410

http://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication

EDIT:

I put this C++ program together, and I've modified in every way I can think of (moving %p around, doing it too many times, breaking up the equations and the like).  I can't get it to result in the proper results.  Anyone mind checking it out and see what you can find please?

http://coliru.stacked-crooked.com/a/26f9ed24ed5a86ed

The magic phrase on that page is in a finite field.  Here the finite field is the integers mod p, where p is the number 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1 (see here).  So all the arithmetic in your equations isn't ordinary arithmetic of integers or real numbers; it needs to be done mod p.   See http://en.wikipedia.org/wiki/Modular_arithmetic.  For addition, subtraction and multiplication, you can use ordinary integer arithmetic and compute the remainder mod p at the end.  For division, you will need something like the extended Euclidean algorithm.  Of course, you will also need to be using arbitrary precision arithmetic if you are not already, since numbers of this size are much too large for standard C++ types like long int and double.


Btc in my hard drive I really need some help.

So as you know, BTC is out there, and I recall at the beginning of 2015 when it was really not a big deal, I decided to get learn more about btc and somehow I downloaded a type of software in my laptop that allowed me mine BTC now, my laptop ran for days and really I thought it was not a good idea  i decided to cancel the process, but somehow it looks like I mined some btc, now my laptop got really full on space  so i took it to the apple store and they figured out what happened,this happened at the beginning of this year 2017, I had an external hard drive and i put all those codes, blocks, pages however they may be call into the folder and they genius guy told me that i may havce some good money there bc it was a lot.

now, with that story put out there, my question is; how can i transfer those things from my external hard drive to a physical btc wallet? so i can somehow enjoy it.

any advice will highly appreciated it.

Nope. PC mining became unprofitable in ~2014 so you may not have mined bitcoins.

What you probably did was downloading Bitcoin Core and synchronising it (downloading and storing all the Bitcoin transactions)

Sorry, but you probably haven't earned bitcoins.


What is the genesis block? What is the genesis block? In which ways is it important or different from other blocks?

It is important, because it is used to seed the block and chain databases before syncing can occur (you need a block to build on). It's the root of the tree of blocks, forks, and ultimately the chain tips that represent the chains your software is tracking.

It is imported differently to others, as it's coinbase transaction is not included in the UTXO set (it's unavailable to be spent)

Changing the genesis block is a way to definitively fork yourself away from the bitcoin blockchain, ie, start a new network with it's own separate history.

However, some coins do share a common genesis block (Fluttercoin IIRC, shares Litecoins for whatever reason), but the network is forked by the use of checkpoints (genesis might be the same, but block 1 is checkpointed to Fluttercoins, instead of Litecoins).


Bitcoin fees as of 2017-10 range from $3-$10 to send. How is this going to be sustainable with an increasing price? Sending anything less than $10 is not feasible if the bitcoin fees are greater than $3. As the Bitcoin price increases to say $10,000. The fees would be much higher. And since fees cannot be lowered below .0001, how is that going to scale bitcoin in the future with an ever increasing price?

And since fees cannot be lowered below .0001, how is that going to scale bitcoin in the future with an ever increasing price?

As demand for block space increases, it is anticipated that less valuable transactions will be moved off-chain to use solutions such as the lightning network.


Strongest vs Longest chain and orphaned blocks Satoshi writes at the bottom of page 3 of his white paper that "If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer." It seems here that the correct chain is the longest one, although maybe satoshi was just being a little careless with phrasing.

However, I have read other places that nodes choose the correct chain in Bitcoin by selecting the chain that represents the most work (or, in other words, the chain that would be hardest to undo). I'll call this the strongest chain. This is not necessarily the same as the longest chain since, for example, it is conceivable to have a block which took many more hashes to find a valid nonce than two other blocks with a much easier difficulty level. This stack exchange is one place that I have read this.

Question 1: Which is the correct method that nodes use to determine the correct chain, longest chain or strongest chain?

My second question is more relevant if the answer to question 1 is that the correct chain is the strongest chain. It relates to orphaned blocks.

If the correct chain is the one that represents the most work then why are orphaned blocks such a problem? It seems like if a node solves a block and broadcasts it then everyone will know about it in a matter of seconds and then can start mining on the new block without any wasted work. Even if 2 miners solve a block at (near to) the same time, most blocks will see the two new blocks and choose the one with the lower header hash (because it is harder to find lower hashes). It seems that the nodes should come to a consensus in a matter of seconds then, if the correct chain is chosen by strongest (rather than longest) chain. The only time that a miner could spend working on the wrong chain would be time spent mining between receiving a solved block which is soon after replaced by a different solved block with a slightly lower hash. How long could that be, 10 sec?

Question 2: Are orphaned blocks a big problem for miners? If the block generation time were 1 minute, instead, would orphaned blocks be a much bigger problem?

The "longest" chain is the one with the most work. A chain's work is equal to the expected number of hashes it would take for someone to replicate a chain of the same number of blocks and the exact same difficulty steps. So currently each block adds about 266 work to the chain because it takes on average ~266 hashes to solve a block with the current difficulty. Blocks with less difficulty add less work. (The current total chain work is around 280.) However, two blocks in the same difficulty period always add the same amount of work to the chain. A block with a lower hash is not considered better than one with a higher hash.

Satoshi didn't initially realize that choosing the correct chain by just counting blocks allows for some extremely easy attacks. Version 0.1 just counted blocks. That's why the paper just says "longest". The idea of "chain work" was added a little later.

Resolving orphans as you suggest might actually make orphans more likely because miners would be incentivized in some cases to try replacing the most recent block rather than extending it, especially right before a big difficulty adjustment or when the most recent block contains a lot of fees.

Orphaned blocks happen every now and then. Eligius reports around 2% orphaned blocks. They would indeed be much more common if the target time was 1 minute since blocks would be generated faster and there would therefore be more opportunity for conflicts between blocks.


any limitation to use "bitcoind - zapwallettxes" to reverse unconfirmed transactions? I read the following lines in some post about how to reverse a bitcoin transaction:

"How to stop/reverse a Bitcoin transaction without confirmations:
Run bitcoind and with -zapwallettxes.
This makes the wallet "forget" any unconfirmed transactions, thus enabling you to reuse their inputs."

My question is: Is this method only applicable to specific wallet? I use blockchain.info wallet and have some unconfirmed outgoing transactions not yet confirmed.

Run bitcoind and with -zapwallettxes.

bitcoind is the daemon version of the original Bitcoin wallet maintained by Bitcoin Core. bitcoin-qt would be the GUI version.

The option -zapwallettxes is specific for the Bitcoin Core wallet. It 'forgets' spend outputs and allows you to respend them. However this does not imply that other bitcoin nodes on the network accept a new transaction with the same (already spend in your first transaction) outputs.

-zapwallettxes is only affects your local wallet.

Your transaction can not be reversed. Probably the best thing to do is wait. Your transaction will confirm eventually.


Does calculating how many bitcoins I have take longer as time goes on? I have read that the blockchain is a series of transactions that record one person giving bitcoin to another.  Please correct me if this assumption is wrong as it is the basis for my question.  So, over time, doesn't it take an increasingly long time to figure out if you can accept Bitcoin from someone because you will have to go through every transaction in the history of the blockchain to validate that the person giving you Bitcoin does indeed have that Bitcoin in the first place?

With a naive implementation, yes, but in practice, no, it is not a problem.

This is because any developer that knows what they are doing is smart enough to create a database which, at the very least, records each transaction (or its position on disk) and its verification status. So when you receive a new transaction, instead of having to walk back through history, you just need to look back to the referenced previous transaction. As part of validating a transaction, you check if the previous transaction was valid. So if a transaction is marked as valid in your database, then you can be sure that the transactions that preceded it  are also valid. Thus there is no need to actually look through history and re-validate those transactions.

Since it ultimately just comes down to a simple database lookup, it does not become harder to validate new transactions.


Bitcoin rawtransaction fee Create a raw transaction createrawtransaction (transactions, vouts, amount and where to send)
then specify the commission for the miners fundrawtransaction feeRate But when I start checking or signing and sending, the commission becomes bigger .... What is it connected with?
p.s sorry for my english :)

The transaction fee calculated for the transaction by fundrawtransaction cannot actually predict the transaction's final size. This is because signatures are not fixed in length and can be smaller than what is predicted. However, in order to be sure enough fee is paid, fundrawtransaction will always assume the maximum signature size. This means that sometimes the signature will end up being smaller which means that you end up overpaying a little bit in fees. The feerate will be higher because the fee has stayed the same but the size of the transaction is smaller than predicted.


How do I access information on blockexplorer.com or blockchain.info without issuing requests to those websites? Suppose I want to

get the balance of an address I don't own, or
see all the transactions recently made

Bitcoin Block Explorer has this information, but I don't want to use it

because of security (they might lie)
because of privacy (they might log queries)
because it introduces an additional point of failure
because it's not terribly quick, being a free service and all

How can I get this information from my bitcoind?

bitcoind doesn't give you a way to query this, but by looking at the files it writes to disk, we can build our own tools that let us look at this. One such tool is Abe, and this is how you use it:

Installation (Ubuntu)

I'm assuming you have the standard bitcoin client running already.

Download Abe. Unpack it, and run python setup.py install

Go into abe.conf and add these lines:

# SQLite3 example:
dbtype = sqlite3
connect-args = abe.sqlite
# Specify port and/or host to serve HTTP instead of FastCGI:
port 2750
host localhost

A note about firstbits

If you want to do firstbits lookups, you need to add one more line to the config.

use-firstbits

Note that you need to do this before you run abe, or else you'll need to run Abe.reconfigure too.

Back to the normal installation

Run python -m Abe.abe --config /path/to/abe.conf

You should see the screen get spammed with

block_tx 38944 39254
commit

At time of writing, this will need to count up to 220,000. This took me about 8 hours. After the first startup, it will load in about a second.

Try opening http://localhost:2750/. If it shows no data, then there was an error. The output that the abe command produced immediately before saying that it was listening should give you some sort of insight.

Now your application can issue http requests to find out about the blockchain! There is a link to some documentation (http://localhost:2750/q), but you'll mostly be interested in

getreceivedbyaddress (http://localhost:2750/chain/Bitcoin/q/getreceivedbyaddress/ADDRESS)
getsentbyaddress (http://localhost:2750/chain/Bitcoin/q/getsentbyaddress/ADDRESS)
fb (http://localhost:2750/q/fb/ADDRESS)


Is there a 'BTC Refund Department'? I have been scammed 6 months ago.
Now someone is calling me from BTC REFUND DEPARTMENT. He said that I have under my name the bitcoins that have been scammed. But the way to take this amount is to synchronise my wallet with the address that the amount is under my name. The issue is that he is asking for 10% of the amount to be added in the wallet and send the new bitcoins to blockchain and then after 15 minutes all the funds will be in my wallet.
Has anyone had a similar experience? Is this true or is just another scammer?

I have been scammed 6 months ago

Then criminals expect you to be gullible and foolish. You are a prime target for them. So they'll try new ways to trick you.

BTC REFUND DEPARTMENT

No such thing.

synchronise my wallet with the address

They want to fool you with a watch-only address, where your wallet shows an amount of money that belongs to someone else not to you. Addresses are not secret. Anyone can add any bitcoin address to their wallet but that doesn't give you any control over money.
Bitcoin wallets do not actually contain money. Wallets contain a secret number called a private-key that a wallet can use to control money. Importing an address doesn't give your wallet this secret number.

the amount is under my name

That's not how bitcoin works.
Some businesses that sell bitcoin might ask buyers to set up a named account but that's outside the real Bitcoin system.

hi is asking 10% of the amount to be added

This is often called "advance fee fraud". Don't be tricked. There is never a need to pay any fee to release money. If there were, it could just be deducted from the amount being returned, you wouldn't have to pay it first. This is a favourite trick of confidence tricksters.

Is this true or is just another scammer

It's not true. It is just another scam.

See also answers to questions about

watch only addresses
non-spendable addresses
fraud (Bitcoin)
scams (Personal Finance)


How does Bitcoin comply to GDPR Update: This related question focusses on users own data. My question is mostly asked from the perspective where a person may enter someone elses personal data, like someones sexual preference.

In the data world GDPR is currently a very hot topic:

personal data must be protected and not retained too long.

For normal companies and systems it is already very difficult to meet the letter of the regulation in practice, however I image that for bitcoin it is even challenging on a much deeper level. Two core principles:

Data must be visible by all
The full history must be preserved

This brings me to a question:
How does Bitcoin respond to the introduction of GDPR?

And as bonus question:
What does this mean for other blockchain applications (like corporate concepts, not specifically for currencies)

How does Bitcoin respond to the introduction of GDPR?

Bitcoin is not a person or legal entity that is subject to law. Only people or businesses using bitcoin have to comply with GDPR.
So far as I know, storage of personal information is not a part of the specifications of the protocols or algorithms that comprise Bitcoin.
Specific pieces of software might allow you to store personal information. For example, wallet software might enable you to keep a list of people, addresses of their bitcoin wallets and your text notes about them. The users are responsible for complying with GDPR. The software writers are only responsible for enabling this compliance (e.g. providing a delete function or something else GDPR compliance needs). The prime reposbility is with the user, if the software they use cannot be used in a way that complies with GDPR they must find other software.


can cryptocoins be put to good use? now or in the future? it would be amazing is there was a Cryptocoin that could be put to good use.
Like some sort of protein folding.
Curecoin, CureCancerCoin exists but it doesn't put anything towards computational research projects.
Folding@Home is an example of something that could be integrated to a cryptocoin.

Is there anything other than Curecoin or CCC?

Primecoin is an example of a well-known cryptocurrency that is doing something useful. As its name implies, its utility relates to prime number discovery:

  The innovative prime proof-of-work in Primecoin not only provides security and minting to the network, but also generates a special form of prime number chains of interest to mathematical research. Thus primecoin network is energy-multiuse, compared to bitcoin network.


How can I use multisig / split keys using My Wallet? I was sure that My Wallet supported multisig, but I can't seem to find it now.

How can three users of My Wallet create an address that is only spendable if at least two of them cooperate? Or is this not implemented yet? If so, when is it due?

This is the latest info I have seen from Ben who runs blockchain.info.

  Question: The escrow function seems to be gone. Will it return?
  https://blockchain.info/wallet/escrow?

  Ben: The escrow feature was removed because not enough people were using it. I think maybe it was just too confusing/not well documented enough.

I did not see any info on if/when it will return.


Is it possible, with bitcoin-core or btcd, to manually set the scriptSig field in a coinbase transaction? I am talking about when using regtest or simnet modes.

For context, it is so that I can create coinbase transactions with reproducible txids.

It is not possible to do this in Bitcoin Core. If you want to have control over the coinbase transaction, you will need to use external mining software that allows you to do that.

Since the difficulty on regtest is so low, you could have a simple python script that produces blocks with your specific coinbase. You don't need actual mining software as the difficulty is low enough to be found almost instantaneously with a naive mining implementation.


Why can't we design a bitcoin that does useful work? The bitcoin network, including every miner, is the biggest computing project that humanity has created. Thus I ask: why, instead of using it to generate useless data, don't we use it to generate meaningful data, such as theorem proofs or something similar to folding@home?

Solving SHA256 hash problems on Bitcoin is useful in the sense that secures the Bitcoin blockchain, but if your question is: "why can't it do something computationally useful as a side-effect?", then I think the answer is "we don't know how". For Bitcoin to work, the proof-of-work that miners do must have the following properties:

Easy to verify solutions
Hard to find solutions
Difficulty of finding solutions can be precisely quantified
Provably inseparable from the block it secures

Cryptographic hash functions like SHA256 satisfy these four properties. I don't think automated theorem proving fits the bill because, as far as I'm aware, there is no way to prove how difficult it was to find the theorem that you proved. General purpose grid computing, like BOINC, doesn't fit the easy-to-verify requirement, at least in the context of Bitcoin. (In fact, I think this is an active area of research in grid computing, called the "cheating problem".)

If there some proof-of-work scheme that satisfies these four properties and also has some useful computation as a side-effect, that would be interesting. I'm not aware of any.


Laymans guess to determine how many hashes must be computed to you find a specific value I have a question about bitcoin, lets say that the output is uniformly random and that it is 256 bits in length.  The output of the hash function y=H(t) begins with 25 zeros - how many times would one have to call the hash function to get something that starts with 25 zeros?

Secondly, how does one verify the solution and how many hashes would be attempted to solve it?

It's pretty simple. Since the hashes are uniformly distributed, 25 zeroes is as likely as any other possible value for the first 25 hexadecimal digits. There are 16 possible values for each hexadecimal digit, so the number of possible combinations is 16^25, or about a 1,2676506×1030. This also means that on average, one in 1,2676506×1030 hashes will start with 25 hexadecimal zero digits.

To verify the solution, you just compute the hash once and check if it starts with the required number of zeroes. So, it's 1030 times easier to check the hash than to find it.


Increase a transaction fee in bitcoin core I marked my transaction with "Request replace-By-Fee"* in my bitcoin core wallet, and now while I can increase the transaction fee, I can only increase it by a tiny bit, and I can't set it to what I really need. (forcing me to increase the fees 15 times in a row)

Is there any simple way for me to increase the fee more significantly without creating all of these intermediate transactions?

* By the way, a very bad name for "allow future fees increase"

The bumpfee RPC command takes a "totalFee" argument. When passed, this is the total fee that will be used for the replacing transaction.


What is crypto-proof UTXO set? There are many opinions about getting the actual UTXO set of blockchain.

Do you think that this important database must be based on data which saved on disk and never modified after, only appended?

I mean that only in this case of history based calculations, provide high level of node security.

Is it true that UTXO set which has the full node for to verifying transactions calculates only from recorded on disk information? Or it is a compressed data received from the network?

In bitcoin, the UTXO set is derived independently by every full node by processing and verifying transactions in blocks. It is then stored on disk until it is spent. When a UTXO gets spent, it gets removed from the UTXO set so the UTXO set is definitely modifiable. When full nodes verify transactions, they also use the UTXO set on disk to check the validity of each transaction. Full nodes have to make sure that UTXOs consumed as inputs in a transaction actually do exist in the UTXO set, otherwise a transaction will be invalid.


Is it possible for a valid block to be added to an invalid one, and have it accepted by another client? This wiki page says invalid blocks aren't counted towards determining chain length and that make me want understand how invalid blocks are treated.

Can an valid block be added to an invalid one.. and have it accepted by one or more clients?

If so...

Do miners of invalid blocks receive a reward for the block? Are the Tx's valid? Are there any examples?

Suppose an invalid block is created and valid block is added to that invalid one.  Both blocks are added to the primary chain. ( assume the attacker has 25% compute and has a custom client that pushes both transactions to all peers)

Since every block has a reward, is the reward in the invalid block counted?
Are the transactions within an invalid block still considered valid?

I'm interested in tracing the transactions the occur from these "broken" blocks and to see if my hand-coded client processes the transactions correctly.

As every Client verifies each block they receive and reject every Block that is invalid, this situation is rather unlikely to happen. However, if by chance some invalid Block would propagate (such as in case of value overflow bug, or perhaps by being spread by some alternative Clients that don't follow the Protocol to the letter), it would eventually be wiped out of the Block history and orphan all Blocks attached to it. Alternatively, the Protocol could change to accommodate the Block, but that is a lot less likely to happen.

When part of the Block Chain would become invalid, all Transactions contained in it would be re-evaluated - coin generation Transactions would be discarded, all Transactions that spend their outputs would also be invalidated, and all other Transactions that are still valid would be added back to the pool of Transactions to be added to future Blocks. Same thing would happen in case of some Blocks being overwritten with a longer Chain of Blocks.

All in all, an invalid Block being accepted as valid and having valid Blocks appended to the Chain after it is a bug. Such cases have happened in the past at least once, and the result has been to fix the bug and erase the invalid Block along with all other Blocks attached to it. All normal Transactions from those Blocks would have to be added again to newly created Blocks and any coin generation Transactions would be invalidated.


With the current hashrate, how does it still take 10min to solve a bitcoin block? No matter how high the difficuly is (or how low the target is), I don't understand how the Bitcoin network takes an average of 10 minutes to solve each block.

For any given block header, there are only 2^32 possible values for the nonce. Even if we take into account that the timestamp can be changed by up to 1 hour (for example), that's 3600 x 2^32 possible combinations, which is approximately 1.5e13

On blockchain.info it says the current hash rate of the network is 7,991,378,504 GH/s, which means that, every second, there are multiple orders of magnitude more hashes being calculated than the number of possible hashes that can result from the current block header.

So howcome blocks aren't solved in only a few seconds, and take about 10 minutes instead?

I understand that miners want to include as many transactions as they can in a block to collect the fees, so one could argue it's best to wait until there are many transaction in a block before solving it. But even that doesn't make sense, because there's absolutely nothing to lose in solving each block as fast as possible anyway.

Mining basically works like this:

Make a candidate block, try all nonces.
If none yielded a valid block, change something in the coinbase transaction.
Repeat from step 1.

Miners collect transactions and then try to create a valid block by bruteforcing nonces. The difficulty of creating a block is related to the maximum hash value a valid block may have.

For example the current blockchain head (while posting this) has a block hash of 00000000000000000077d9c18fdbd5cf45b2652fe6db9089558eb8fc9fc3b397.
As you can see it has many leading zeros, because most hashes above this value are rejected. With the 2^32 nonce values and other header fields you cannot try enough blocks to be likely to hit any block hash small enough. Miners will switch some bytes in transactions (normally in the coinbase) to create even more new block candidates.

Furthermore different miners will try different blocks, as they should have different receivers of the coinbase transactions.


Transaction not showing up as confirmed on MultiBit I tried to send a Bitcoin transfer yesterday at noon and after more than 120+ confirmations it's still unconfirmed.
I used MultiBit as wallet, I set fees but still nothing.
I was used to super-fast transaction, the maximum I've waited in the past was 15 mins.

Did I do something wrong or is it just the usual time it takes?

Here it is:
https://blockchain.info/tx-index/ba8c1f8e3c2b526a0ed842eda8e6c75650c9ac12ba093b79b023556edf8bcec7

A transaction cannot be both confirmed and unconfirmed. Your transaction is confirmed, just that your wallet is not showing you the right information. This is not normal behavior. This happens when your wallet is no longer synchronized with the rest of the network. You should be able to fix this by going to Manage Wallet and clicking the Repair Wallet button. Then follow the instructions in the dialog that appears.


interacting with bitcoin over docker I've created a docker container of an ubuntu machine, loaded it up with all the dependencies specified in the unix build doc and then built bitcoin and run it with the following command:

./src/bitcoind

after that there's no output or evidence that anything is happening, the terminal is just hanging there, clearly something is going on- but I don't know/can't see what it is.

how can I examine the activity? For instance, see the coins that are being generated in my wallet, etc.

I've tried this proposed solution, i.e. to write

bitcoind getinfo

but I got the error

Error: There is no RPC client functionality in bitcoind anymore. Use the bitcoin-cli utility instead.

Regarding -regtest

I tried with:

./src/bitcoin-cli -regtest &

and I got the error:

too few parameters (need at least command)

the terminal is just hanging there

Yes, if you want it to run in the background, you need to run with the -daemon flag.

  how can I examine the activity?

You can look at the debug.log file (in the datadir), or you can run with the -printtoconsole flag. You can increase the verbosity using the -debug flag (or specify a specific category, for example -debug=mempool; to see the various debug categories and more, use -help).

  For instance, see the coins that are being generated in my wallet, etc.

The built-in miner was removed in Bitcoin Core v0.13.0, as it was not even useful for testing purposes anymore. If you want coins, you'll need to either buy them, get someone to send you some, or run a mining setup (which at the time of writing almost certainly requires custom ASIC hardware).

  I've tried this proposed solution, i.e. to write

    bitcoind getinfo

You need to use bitcoin-cli now to communicate with bitcoind (since a few years ago...). The getinfo command still works but is deprecated. More specific information can be obtained using the RPC calls:

getblockchaininfo
getpeerinfo
getnetworkinfo
getwalletinfo
gettxoutsetinfo
getaddednodeinfo
getmempoolinfo


Is Bitcoin Core required for wallet projects? My team wants to create a cryptocurrency service provider platform to Sell/Buy BTC and something else in form of web/mobile app. It's about one month that I have been studying different articles about its requirements. The crucial things we need in this project are:
1- Creating wallet for customers
2- Let customers to send/receive BTC from/to their wallets

I found both API providers, and something else like Bitcoin Core, Bitcoind, etc.
We prefer to build our own platform and avoid depending on 3rd party vendors.  May you tell me do we need Bitcoin Core to do our project needs? If your answer is yes, can we install it on a server and access to it remotely via API?

Bitcoin Core is not required to do anything, but it is a useful software that you can use instead of trying to reimplement everything it does. Or you could use some other software that does the same thing. However Bitcoin Core is by far the most used and reviewed software compared to other node and wallet software.

You can use Bitcoin Core to create wallets and let customers send and receive to/from those wallets. However Bitcoin Core is not well optimized for having a large number of wallets (note that a wallet is not the same thing as an address), so it may not be the best for your use case. Of course, if you instead use the traditional model of one exchange wallet and just giving out depositing addresses to users, it's fine (users should not expect to "send from" "their" address).


How do I transfer all funds from one wallet to another? I have some bitcoins in an old bitcoin-core wallet and would like to transfer all of them to a new BIP32 wallet. I tried doing sendtoaddress with subtractfeefromamount=true, but bitcoin transferred all but 0.0005BTC to the new address (I suspect some rounding issue when calculating the fee and amount to send). So now I have an address with 0.0005BTC (plus some other addresses with a larger amount). How can I reliably transfer all funds so that all the addresses in the old wallet have zero balance?

Furthermore, is there a way to verify that all addresses for which I have the private key have a zero balance?

You can create a transaction having an output value equal to the entire balance of your bitcoin core wallet. The last parameter of sendtoaddress is a boolean signifying whether to include transaction fees or not, which you can set as true. The sendtoaddress API has a mechanism of generating a new address for the change remaining from the value you have given.

Another way would be to manually create the transaction with all the inputs from the addresses which have balance and sending it to the new wallet address. Remember to keep some difference in the input and output of the values which would be treated as transaction fees.

As for the last question, if your question is pertaining to the addresses in your old bitcoin core wallet, then you can use the listaddressgroupings API to get a detailed balance of each of the address your wallet has created.
If the addresses don't belong to a core wallet, then you can simply search for the balance on https://blockchain.info/address/<your_address>


How much trust is placed on Satoshi Nakamoto? Is the safety of bitcoin dependent on the creator of it being a trustworthy person? Or would it be safe to use even if it turned out the creator's day job was working at the NSA?

Is the safety of bitcoin dependent on the creator of it being a trustworthy person?

No, the safety of Bitcoin is not at all dependent on the identity of its creator.

The source code is public. The paper is public.

  Or would it be safe to use even if it turned out the creator's day job was working at the NSA?

Again, the genesis of Bitcoin is unrelated to its current state or future state, except through the data of the blockchain.


Mt. Gox had 5 billion bitcoins? In the statement of liabilities issued by Mt. Gox after its bankruptcy it shows the following figures as totals:

The statement amount of "Deposited BTC" is 5,202,383,086.88638 bitcoins, which is over 5 billion bitcoins. Since at the time of Mt. Gox's bankruptcy in 2013, there were only about 10 million bitcoins in existence, the statement would seem to be impossible.

Is there something I don't understand about the Japanese number system?

It looks like some of the claims were spurious and had grossly exaggerated values. The accepted claims by the bankruptcy trustee were:

45,609,593,503 JPY

which is more reasonable.


How to make bitcoind connect to more nodes? Let's say I have a dedicated server just for my bitcoind and for better reliability and some security reasons I want it to be connected to a much bigger number of nodes than it is willing to do by default (about 40-50).

Providing that I have enough resources, how can I set my bitcoind to keep a specific number of connections to other nodes? Is this possible without recompiling it?

Note: there's a maxconnections option which sets the upper bound, but it doesn't seem bitcoind strives to reach it. Need to kick it off somehow.

Bitcoind will never make more than 8 outgoing connections. By default, it will allow up to 128 connections (see -maxconnections), but that includes incoming ones.

Available connection slots of fully synchronized nodes are a limited resource on the network, so they shouldn't be wasted. As long as you have enough connections to be sure that at least one is not trying to attack you, you should have enough.