How do I get the address that received a payment? I am using BitcoinJ and wondering who user that I should credit, all users have their own receiving addresses. Please post an example also, if you have time. :)
Current code:

    wallet.addEventListener(new AbstractWalletEventListener(){
        @Override
        public void onCoinsReceived(Wallet wallet, Transaction tx, Coin prevBalance, Coin newBalance) {
            String txid = tx.getHashAsString();
            long received = newBalance.value-prevBalance.value;
            String address; // The receive address that the payment was sent to.
            int UserID = MySQL.getUserIDbyAddress(address);
            // Here will I credit the user.
        }
    });

I found out in the end how to do it, here you can see:

    wallet.addEventListener(new AbstractWalletEventListener(){
        @Override
        public void onCoinsReceived(Wallet wallet, Transaction tx, Coin prevBalance, Coin newBalance) {
            String hash = tx.getHashAsString();
            long received = newBalance.value-prevBalance.value;
            String address = null;
            for (TransactionOutput txop : tx.getOutputs()){
                if (txop.isMine(wallet)){
                    address = txop.getScriptPubKey().getToAddress(params).toString();
                }
            }
            int UserID = MySQL.getUserIDbyAddress(address);
            // Code...
        }
    });


How is the difficulty of bitcoin mining propagated? Let's say the current difficulty is set as finding a hash with 4 leading zeroes; once this is found, a block with this hash is propagated. Every client that receives this block checks that it has 4 leading zeroes and accepts this block as valid, adding it to their own chain.

My understanding is that the only information a miner sends out, when he solves his hash, is this block he has created (containing the solved hash and details of all the transactions that he used when creating the hash). This information, and only this information, then propagates to the rest of the network.

Now, how does the "central bitcoin server", or whatever it is, then propagates the change in difficulty every 2 weeks? Would it require everybody to update their client software to recognize that new blocks are only valid if they now have 5 leading zeroes, or is there some genius mechanism that I'm missing? On a side note, I don't really understand how forks are resolved; is this relevant to how this issue is dealt with?

The difficulty is stored in the block in the Bits field. When any server receives a block, one of the things it does is check if the value in this field is correct. If it's not a block where the difficulty changes, it must have the same difficulty as the previous block. If it's a block where the difficulty changes, then it must have the correct difficulty according to the well known Bitcoin difficulty adjusting algorithm.

There is no "central bitcoin server".

Forks are resolved as follows:

Blocks that are invalid are ignored. Only block chains consisting entirely of valid blocks are considered.
The blockchain that would likely have taken the most effort to create (highest total difficulty) wins.


bitcoin mining on a laptop gpu, nvidia GT 120m? i have a laptop with a discreet GPU, no integrated ones.
its a Nvidia GT 120m in an ASUS laptop.
i never use the laptop, so i decided to turn it into a bitcoin miner using bitminter.
at the moment it is just doing 4Mhps. while one of my desktops with a nvidia 8800GTS is doing 13Mhps.
i believe the laptop gpu is suppose to be faster.
anyone have any solutions to a problem like this.
oh and both systems use ubuntu 12.04

Laptop gpus are no good for mining bitcoins. Not anymore, at least.


Can miners reject transactions from an address? It is alleged that the stolen Bitstamp coins are in this address. In theory, could miners agree to reject all transactions from this address? And if so, would all miners need to agree or just more than half?

Technically it is possible to blacklist addresses, and it needs just the majority of the mining power to agree.

The problem is arriving at the agreement: Nobody stands to gain from witch-hunts, so a consensus to block an address would have to be carefully built on solid proof, which is hard when there is no central organs with jurisdiction, nor a way to get a statement from the culprit.

Also, blacklisting addresses, just like tracking tainted coins, has a strong implication on what we view Bitcoin to be: One of the sources of Bitcoin's value is that bitcoins are considered fungible – that each individual does not need to care about the history of a bitcoin, because a bitcoin is a bitcoin. If we start treating bitcoins differently in accordance to their transaction history, it will make the bitcoin economy more complicated and less useful.


What are some of the pitfalls of a 100% proof of stake currency (pos) like NXT? Bitcoin has the vulnerability of a 51% attack for a proof of work currency, but what pitfalls does a 100% proof of stake (pos) currency have like NXTcoin?

One can verify legitimacy of a Bitcoin branch simply by checking proof-of-work of the block headers. In Nxt it's necessary to know who the owner of the coins, so the whole blockchain data must be downloaded.

This seems to be the only fundamental pitfall that arises from very nature of Proof-of-Stake cryptocurrencies.


Recovering LTC coin sent to a BTC address I have mistakenly sent LTC coin(Using bittrex) to my BTC wallet(Zebpay). I have not received the coins yet.

The transaction is showing 6+ confirmations on blockcypher and not showing anything in blockchain.info.

Following to this, Bittrex has advised me to research how to remove a private key from a Bitcoin address and import it into a LTC wallet to recover these coins or contact someone from the LTC community for help.

Does anyone know how to resolve this problem?

I sent my LTC to my Trezor BTC wallet. There is a Trezor recovery function that will recover it if it was sent to a Trezor address.

Hope that helps anyone with a Trezor out!


Query publicly available full nodes I don't want to run a full node yet, but I want to build an application. How and what do I use to query publicly available nodes? What nodes besides blockchain.info are publicly available for me to query over HTTP/HTTPS?

Depending on what you want to do there are several answers.

Top 2:

https://longhorn.bullpay.com - Up to 2,000 Tx's returned per call
https://live.blockcypher.com/btc/ - Up to 2,000 Tx's returned per call

These may work for you but have reduced thru put:

https://blockexplorer.com - Up to 50 Tx's returned per call
https://blockchain.info - Up to 50 Tx's returned per call

All these services act like a full node (at least bullpay and blockcypher have the ability to send transactions, i'm unsure about the other two in this regard). They all have free versions. Some have paid versions to increase the number of requests you can make per second for increased scalability. The links are to their explorers. API documentation can be found on each site.

So again, it depends on what you're trying to accomplish. If you're working heavily with historical data for things like auditing, you'll want to obtain more data faster. Focus on the first two. If you're just messing around then any of them would work with varying degree's of effort.


Energy consumption while mining I am new to Bitcoin and I read some article about bitcoins and Most articles says "When using CPUs, GPUs, or even the older ASICs, the cost of energy consumption is greater than the revenue generated."

What I want to ask is why people still trying to mining with their CPUs and GPUs?

Just for fun. Many actions can't be explained from the point of view of logic


how to set the transactions fee using the RPC call? I am creating the web wallet for the bitcoin , I want to allow web wallet users to set the transactions fee .

Is their is any rpc call available for setting the transactions fee (for setting transactions priority) ?

Yes there is ‘estimatesmartfee’ which computes fee with high confirmation probability within n blocks.


Getting paid by BitCoin on my website using Credit Card Somehow, I think it's a trivial question yet I couldn't find an answer for it.

I have a website that gives online services. Like Image hosting etc'.

I want to receive money in BTC, but most people yet does not have BTC. So I thought, maybe they could pay using CreditCard, it will be converted to BTC and I will get it in BTC.

Is there a service that can do that for me ? Like a pay-pal on my website that people put in their CC details and I will be paid in BTC. I am aware that there will be a fee for that.

Thanks.

cant think of a direct way.

merchant CC service
have them direct deposit to https://www.bitwage.com/

i doubt the connection will work since most merchant accounts will want to be able to pull funds from a bank in the event of a charge back.  but you merchant acct may decide to hold on to funds to make up for the loss.

might be better to get your customer to sign up for circle, coinbase/gdax, gemini, localbitcoins or one of the many other exchanges and have them send you bitcoin.


how do I use the getwalletinfo RPC? I can't seem to get a firm grasp of how to use the getwalletinfo RPC in the cmd line as well as in PHP code, The documentation says getwalletinfo doesn't take any parameters, but I've seen ways to send specific requests to the daemon this RPC. So, my question is, how do I use the getwalletinfo RPC in PHP to get information of a specific wallet?

getwalletinfo does not take parameters.

It sounds like what you are looking for is how to send getwalletinfo to a certain wallet loaded into Bitcoin Core. The way to do this is to use that wallet's API endpoint. The endpoint is /wallet/<name> where <name> is the name of the wallet you are trying to send commands to.

So the full URL that you need to send your RPC requests to is http://<ip>:<port>/wallet/<name> where <ip> is the IP address that Bitcoin Core is listening on (probably 127.0.0.1), <port> is the port the RPC interface is bound to (probably 8333), and <name> is the name of the wallet.


How can a block regarded as confirmed in bitcoin? I am a little confused with confirmation mechanism in bitcoin PoW consensus.
According to bitcoin wiki:

  After a transaction is broadcast to the Bitcoin network, it may be
  included in a block that is published to the network. When that
  happens it is said that the transaction has been mined at a depth of 1
  block. With each subsequent block that is found, the number of blocks
  deep is increased by one. To be secure against double spending, a
  transaction should not be considered as confirmed until it is a
  certain number of blocks deep.

Let's say if A has 1 btc, and A sent 1 btc to B as transaction T1 and also sent 1 btc to C as transaction T2. It is possible that these 2 transactions are written into 2 different branches.

In this scenario, if miner M1 keeps mining based on branch with T1 and M2 keeps mining based on branch with T2, finally subsequent block for these 2 branches will more than 6, and in most of apps these 2 transactions will be regarded as legal. I am thinking there might be other verification to make a block regarded as confirmed.

My question is: what makes a transaction confirmed? Thanks in advance.

Let's say if A has 1 btc, and A sent 1 btc to B as transaction T1 and also sent 1 btc to C as transaction T2. It is possible that these 2 transactions are written into 2 different branches.

Yes. That's possible.

But there is still no double-spend because only 1 branch will be the accepted one in the future.

Assume that there are more miners. If miners 3, 4, 5 and 6 start mining on the second branch, it grows faster.
After 2 hours, branch1 has 1200 blocks, but branch2 has maybe 1209 blocks.
The chain/branch with the most block is the relevant chain. So miner 1 does not even want to mine on his branch anymore because he knows that the others will ignore this blocks 1201, 1202, 1203.
So miner 1 also switches to branch2 because otherwise, the only wastes electricity.


Can Bitcoin transactions actually be reversed/"undone" by the sender by using/abusing the newish "replace-by-fee" feature? I am watching a live stream of Roger Ver talking about Bitcoin. Yes, I know that a lot of people violently hate him and I will say that I don't like Bitcoin Cash. I sold all mine for Bitcoin very early on, and it seems to me that bigger block sizes are a bad thing.
However, I must admit that many things that he said then and says now seem to make sense. I'm very open to the possibility that he's lying or warping the truth, but this in particular is something which stuck out to me:
Basically, he is saying that Bitcoin has been fundamentally broken on purpose by introducing the "replace-by-fee" feature, which, according to him, allows you to "reverse" (take back) Bitcoin transactions for minutes, hours and "sometimes even weeks" after it was sent.
Is there any truth to this? Is he purely making this up to cause fear and doubt? If so, please give me all the details.
My understanding of the feature is that it simply allows you to "unstuck" a stuck-in-memory-pool transaction by essentially throwing it a few more satoshis for the transaction fee, so that it will not be ignored but rather included quicker by the miners while a lot of Bitcoin transactions are happening at the same time.
Please let him be lying. Another thing that makes me doubt myself and my own understanding of the whole situation is what he says about the Lighting Network, which I agree is "ultra-complex" and "never seems to come into actual use".

Basically, he is saying that Bitcoin has been fundamentally broken on purpose by introducing the "replace-by-fee" feature, which, according to him, allows you to "reverse" (take back) Bitcoin transactions for minutes, hours and "sometimes even weeks" after it was sent.

Not true. Bitcoin transactions with ZERO confirmations were always unsafe to accept as final. RBF just allows you to manage transactions in a better way because fee estimation is difficult in Bitcoin. For example: You can use any algorithm or manually check mempool stats and use a fee rate to broadcast a transaction but lot of other transactions broadcasted at almost the same time with a higher fee rate will decrease the probability of your transaction getting confirmed soon. If required you can replace this unconfirmed transaction with another transaction by using higher fee rate and fee.

Another thing that makes me doubt myself and my own understanding of the whole situation is what he says about the Lighting Network, which I agree is "ultra-complex" and "never seems to come into actual use".

Its easy to use with wallets mentioned in this link: https://blog.bitrefill.com/top-11-lightning-network-wallets-bitrefill-328b5465b1b4
Exchanges: Bitfinex, Okex, Paxful, Kraken(soon), LNMarkets, fixedfloat, sideshift
DEX Protocols using LN: OpenDEX, OmniBOLT


Armory wallet and bitcoin - newbie questions I made a transaction into my armory wallet but I didnt downloaded blockchain before. What happened to my bitcoin?
Can I access my bitcoins when ill be able to get the wallet online?

A wallet stores private keys, not bitcoins (and a watching-only wallet just stores addresses, without their private keys). Your bitcoins are “stored”, for want of a better word, on the global distributed ledger. You can verify this by looking up your address/addresses (not your private keys!!!) on a blockexplorer web site such as blockchain.info — this will show you that your bitcoins are at whatever address/addresses you sent them to. You can do this even if Armory hasn't downloaded the blockchain.

In order to construct a transaction, Armory needs a local copy of the blockchain and it needs the [public] address/addresses from which you're spending. But the transaction will not be valid until you have signed it, and for that, you need the private keys. In a secure set-up (cold storage), you construct transactions in a watching-only wallet (connected to the internet), and you sign them in a full wallet (on an air-gapped computer); such that your private keys are never exposed to the internet.


How do I restore a Lightning Node with active channels that has crashed causing data loss? Is it similar to restoring a Bitcoin wallet? If my lightning node crashes after receiving payments (but before I have closed the channel) can I recover my funds? What happens if I do not have backups of all the channel updates?

Is the restoration process fundamentally different from dealing with on-chain Bitcoin?

Unlike bitcoin stored in an on-chain wallet, funds in the lightning network are stateful. Some channel data cannot be deterministically reconstructed like keys derived from a BIP32 seed. If you do not have backups and your channel counterparty is non-responsive, you will likely experience permanent loss of funds. Make sure to have backups of your channel data made with each additional transaction you send/receive/route to other nodes in the network.

If a node falls down and loses critical state data it is important not to broadcast commitment transactions from old backups. If these commitment transactions have been revoked, the channel counterparty will submit a justice transaction to the network and claim all of the funds in the channel.

This failure scenario can be partially mitigated by nodes that use option_data_loss_protect as specified in BOLT 2. This allows a node to detect that it has fallen behind when reestablishing its connection. This only works when both nodes support this feature and the node that has not fallen behind is honest. If the honest node detects its counterparty has fallen out of sync, it should unilaterally close the channel and the fallen-behind node can then reclaim its funds with data it received on connection reestablishment (my_current_commitment_point).

In the future, state backups can be outsourced to 3rd parties on-the-fly, such that if a node falls down it can call on these 3rd parties to provide the necessary data for channel reconstruction. It has been proposed that Watchtowers - nodes that can be compensated to monitor channels for bad behavior - could also be tasked with storing encrypted state backups.

If you do have a backup you can restore it and reestablish connections with your peers and get back to business!


How do I build Bitcoin from source in Linux? I am running an Ubuntu Virtualbox, how do I build Bitcoin from source and run it in this environment?

I'm using the build notes from the bitcoin core github and I get the following errors when trying to do make -f makefile.unix bitcoind:

net.cpp:48:15: error: 'pnodeLocalHost' was declared 'extern' and later 'static'
net.h:476:15: error: previous declaration of 'pnodeLocalHost'
net.cpp:51:15: error: 'hListenSocket' was declared 'extern' and later 'static'
net.h:479:15: error: previous declaration of 'hListenSocket'
make: *** [obj/nogui/net.o] Error 1

Any recommendation for how to fix this?

I tried commenting out those lines of code in net.h and now I'm getting:

db.cpp:534: undefined reference to 'AddAddress(CAddress, long long)'
net.cpp:1363: undefined reference to 'AddAddress(CAddress, long long)'
main.cpp:1914: undefined reference to 'AddAddress(CAddress, long long)'
init.cpp:493:  undefined reference to 'AddAddress(CAddress, long long)'

could this be an issue with the libraries I've installed? I followed the doc pretty much verbatim.

Basically, you do this:

Download the distribution tarball or repository. You can use the link on the project's GitHub page.
If you used the distribution tarball, unpack it.
Obtain any needed prerequisites. Things you may need include the development packages or source builds of: OpenSSL, Boost, libZ, GLib2, and BerkeleyDB. You should be able to use your distribution's development packages for everything with the possible exception of OpenSSL. I don't know offhand if Ubuntu ships a version that will work with the Bitcoin client (including ECDSA support). If not, rebuild OpenSSL from the source with default options.
Make a copy of the supplied UNIX makefile (called makefile.unix) and call it Makefile.
Adjust the Makefile you created as needed. You may need to: Add include/library paths for the prerequisites if they're not in the usual places. Localize the name of the BerkeleyDB distribution, for example 'db_cxx-5.1' instead of 'db_cxx'. Localize the name of some Boost libraries (on some distributions, most will need '-mt' added to the end).
Type 'make' and hope for the best.
If it didn't work, figure out why and fix it.

One caution: If two builds of the Bitcoin client are linked against different versions of the BerkeleyDB package, they may not be able to read each other's database files (including the wallet.dat file). There is a process to convert the files (dump to text on one version, build from text on another) but it's cumbersome and perilous.

Update: To your two specific issues, the fix is to remove (or comment out) lines 476 and 479 in the net.h file, the extern declarations of pnodeLocalHost and hListenSocket. (Be careful, when you remove one, the line number of the other may change. Identify both changes before you make either.)


Need help understanding how to profit from bitcoin trading (like forex?) I want to understand something very basic. How does trading work between BTC & USD.

Let's say I have 1 BTC at US 100. The naive idea is "buy low" and "sell high". But I don't grasp how that work, ie, how is possible to profit in both directions.

If the value of BTC change this way (value in USD):

  110 85 102 40 70 90 115 130 100 200

What I need to do to turn a profit? And if my plan is that I don't lose more than I invest at the start?

Pretty simple. You just make money on the differences when you buy/sell (taking in to account fees).

In your example, you start with 1 BTC purchased at $100 USD.  Assuming no fees, you would:

Sell at $110 (Profit: $10)
Buy at $85
Sell at $102 (Profit: $17, total: $27)
... and  so forth

Now, you could get even more creative, since you can purchase fractions of BTC.  In this case, you could:

Sell at $110 (Profit $10)
Buy 1.294 BTC at $85 each for $109.99
Sell at $102 for $131.98 (Total Profit: $31.98)
...


How to setup stratum with pushpool and VARDIFF? (litecoin) I'm trying to setup a pool for litecoin mining with support of the stratum protocol and VARDIFF (variable difficulty).

I read the answer of cdecker on the following question How to setup pushpool. This was quite helpful. I managed to setup pushpool and everthing is running quite well (at least I can see CGminer connected and doing something).

I'm just stuck in setting up startum and VARDIFF. I was searching through boards, but I can not find anything that is related to my problem. The only approach I read on bitcointalk was to use "rpc.target.bits" : 18 instead of "rpc.target.rewrite" : true in server.json to adjust the difficulty, but no success :(
For VARDIFF I can not find anything at all.

Any help would be very much appreciated!

i have come back to post up all the information i can for you.

through the last few months of working with Stratum-mining i have come to some conclusions: you need to know python well to get this working on anything but bitcoin... That being said, its possible to install stratum over a current custom pushpool installation through a project I released and am working on. (Currently it is for freicoin but there are two trivial changes you can make to get my implementation to work on litecoin). There is also another implementation of stratum-mining that you can use that was last updated on Jun 6 2013 (i would suggest using this versus my code if you are installing from scratch or using MMCFE currently. my version of the code is designed to be more friendly to version 2 getblocktemplate, where as litecoin only supports getblocktemplate version 1 at this time).

In the future it may be extremely useful to diff these two implementations as they have different database schemas...

In the mean time,
Here's how to install stratum-mining-litecoion a NEW system OR a system with MMCFE

step 1) back up your database
step 2) back up your database
step 3) back up your database

From https://github.com/Neozonz/stratum-mining-litecoin/blob/master/INSTALL

"

> Installation Instructions
> =========================
>
> Step 0. Install litecoind     NOTE: Litecoind currently only supports
> getblocktemplate version 1. This code was changed to support version
> 1.    Set it up and start it!     Downloading the blockchain can take a few hours to a couple days!
>
> Step 1. Install the stratum core  git pull
> https://github.com/slush0/stratum.git     sudo easy_install stratum
> (or if using alternate python: sudo /usr/local/bin/easy_install
> stratum)
>
> Step 2. Pull a copy of the miner  git pull
> https://github.com/moopless/stratum-mining-litecoin.git
>
> Step 3. Configure the Miner   cp conf/config_sample.py conf/config.py
>   make your changes to conf/config.py     Make sure you set the values in
> BASIC SETTINGS! These are how to connect to litecoind       and where
> your money goes!
>
> Step 4. Run the pool  twistd -ny launcher.tac -l -    OR - using
> alternate python  /usr/local/bin/twistd -ny launcher.tac -l -
>
> You can now set the URL on your stratum proxy (or miner that supports
> stratum) to: http://YOURHOSTNAME:3333
>
> Database Setup
> ========================= Table Creation: Tables are auto-created if they don't exist (I will be adding a schema file later)
>
> None: Well, this doesn't do anything, so there is nothing to set up
>
> Sqlite: THIS IS THE DEFAULT! Just set the file path in the config file
> (or keep the default.) Support for sqlite3 is built into recent python
> versions. A couple notes for Sqlite:
>   - Sqlite and threading/concurancy just doesn't work right for that reason it is disabled.
>   - Since threading is disabled, The server will "pause" when archiving happens, this will affect         your miners. However this will not happen
> often (24 hours after finding a share)
>
> Postgresql:
> 1. Set up your parameters in the config file.
> 2. Install the postgresql libraries in your os:   Redhat and the like:        yum install postgresql-libs postgresql-devel    Ubuntu and the like:
>       apt-get install postgresql postgresql-devel
> 3. Install the python bindings    easy_install psycopg2
>
> Mysql:
> 1. Set up your parameters in the config file.
> 2. Install the mysql libraries in your os:    Redhat and the like:        yum install mysql mysql-devel   Ubuntu and the like:        apt-get install
> mysql mysql-devel
> 3. Install the python bindings    easy_install mysql-python
> 4. Create a database and user.
>
> Problems????
> =========================
>
> Is your firewall off? Is litecoin running?
>
> TODO: are there other problems?

"

If you are already using pushpool and a custom frontend and don't want to write over your system, i have a working (but a bit buggy with MBPM due to the nature of my project) "install over" version of stratum mining for freicoin available here https://bitbucket.org/joeswhite/joes-stratum-mining-freicoin/src/8eec8a0b11c6?at=master

this is how to install my version (DO NOT INSTALL THIS VERSION UNLESS YOU HAVE EXPERIENCE CODING!), there is an added step for the litecoin implementation but it is not yet tested by me.

"

> stratum-mining Basic implementation of bitcoin mining pool using
> Stratum mining protocol. This fork includes a database implementation
> for: None Sqlite Mysql Postgresql Basic worker stats are provided (and
> updated) See the INSTALL file for install instructions. For more info
> on Stratum: http://mining.bitcoin.cz/stratum-mining. Original version
> by Slush Updated version by GeneralFault (Tips Welcome:
> 15Zk7DoFYJ7hESpZzmix1WLkomTMGW81c2 ) This version by Joe White
> http://pool.cr.rs (freicoin mining pool) Joe's Stratum Mining Freicoin
> Implementation of generalfault's
> https://github.com/generalfault/stratum-mining that works with Mark
> Friedenbach's https://github.com/freicoin/stratum-mining This
> installation can be put directly over top of your current pushpoold
> Known bugs: Does not handle subscriptions properly upon connection,
> but properly pushes block template and everything submits without
> issue To do: add Joe's Pool front end in to implementation
> (simplebtc's implementation heavily modified) add firewalls, security
> services, add google authenticator, add other things like tripwire.
> how to: Easy: download vmware image go to town make sure to set up any
> and all firewalls, security measures, and other information. manual:
> first download freicoin from freico.in/downloads install freicoin edit
> your freicoin.conf file change the rpc port for security (i like to
> mix it up on each server i use) nano .freicoin/freicoin.conf something
> like this works (freicoin.conf file): server=1
> rpcuser=changethisusername rpcpassword=changethispassword rpcport=4252
> rpcallowip=127.0.0.1 test to make sure freicoind works once you are
> sure of that, then get the git package git clone make the stratum log
> directories mkdir /stratum mkdir /stratum/log/ touch
> /stratum/log/stratum.log recurse in to the directory and edit
> conf/config.py MAKE SURE TO READ AND CONFIGURE ALL SETTINGS!!!! I HAVE
> DISABLED PLUG AND PLAY FOR YOUR SAFETY/SECURITY nano conf/config.py
> ALWAYS BACK UP BEFORE STARTING ANYTHING!!! YOUR DATABASE COULD GET
> SCREWED! I CAN NOT BE HELD LIABLE FOR ANYTHING, ESP THAT! import the
> database if you are starting from scratch (it is not standard and is
> not optimized, you could opt to make your own database and edit
> DB_Mysql.py (or corresponding database) and edit anything that is a
> sql execution (anything that has "select * from, or any other sql
> statements can be easily updated without changing most or anythign on
> the server side schema.sql <- THIS IS THE SCHEMA FOR THIS
> IMPLEMENTATION OF joe's THIS SCHEMA IS NOT OPTIMIZED AT ALL! ALWAYS
> BACK UP BEFORE STARTING ANYTHING!!! YOUR DATABASE COULD GET SCREWED! I
> CAN NOT BE HELD LIABLE FOR ANYTHING, ESP THAT! start a new screen so
> you don't log out and stratum crashes (this is helpful for logging
> too) screen

"

*litecoin specific step
At this point you need to go back and write over (at very least) the halfnode.py block_template.py and coinbasetx.py files with the files provided in stratum-mining-litecoion. most likely you will need to write over all of them. (This is the untested part i was talking about).

"

> ./startjoes.sh it should load up and work, you will see one error on
> submission at this time it is okay this error does not affect any pool
> performance, it is tested working. please update this as there are
> many probable errors. I have included the sql architecture for this
> implementation as it is not standard and can plug-and-play over an
> existing pushpool implementation ALWAYS BACK UP BEFORE STARTING
> ANYTHING!!! YOUR DATABASE COULD GET SCREWED! I CAN NOT BE HELD LIABLE
> FOR ANYTHING, ESP THAT!

"

I am trying to get an implementation up today or tomorrow and can report back any changes i need to make then.

Please let me know if this was a satisfactory answer, if not. I will update this until it is. Thanks for not bashing me ;)


How to receive and manipulate a bip 70 payment object in django python? I'm trying to check to see if the variables are being set correctly by the client and being received correctly by me.
I'm new to proto buffs and django and my code below doesn't seem to be working.
I'm using bitcoin 0.9
I'm trying to capture a refund address.

In views:

from project import payments_pb2
def protoresponse(request):
    xpo = payments_pb2.Payment.ParseFromString(request)
    returnaddress = xpo.refund_to
    transactions = xpo.transactions
    memo = xpo.memo

    xpa = payments_pb2.PaymentACK
    xpa.payment = xpo.SerializeToString()
    xpa.memo = 'success'
    return HttpResponse(xpa.SerializeToString(), content_type="application/octet-stream")

Any pointers would be greatly appreciated :)

I asked this same question in a simpler way without mentioning bip 70 and got the answer here.
The initial problem was that Django doesn't like people posting to your server who arent authorised so I used from django.views.decorators.csrf import csrf_exempt and the corresponding decorator @csrf_exempt as a short term work around for further debugging.
More detailed info can be found by following the link to the simplified question.


Speculation on rate differences between different exchanges Lately there have been quite a bit selling/buying rate differences between different BTC exchanges. Now some of this can be explained by the fact that different exchanges operate based on different real world currencies and there is nothing to it, as the currency switches will diminish all or most differences between BTC rates.

However, since some of the exchanges base their operations on the same real world currency and yet still have noticeable difference between exchange rates, this opens up an interesting possibility for speculation. Note that I haven't done this on a big scale and do not recommend that anyone short on cash does any actual experimentation with this.

So here is a thought and the question. What prevents from X doing the following: first buy BTC from exchange A with real world currency M, then seconds after BTC has settled to X's wallet, he/she then proceeds to put BTCs on sale on echange B for the same real world currency BTC was bought with from exchange A; now assuming, for example, that exchange A's selling rate is N and B's buying rate is N+20USD, this sounds as real as any day trading.

Now what I wonder is that is this really exploitable in money-making sense or do the delays with transactions or some other mechanisms prevent anyone benefiting from different exchange rates on different exchanges?

I think that time prevents people from exploiting your schema. It takes from few days to may be a month to withdraw money from mtgox. Delay from transactions sounds negligible in comparison to this.


Could Bitcoin be implemented without saving the block chain on the HDD? Is the Bitcoin's copy of the block chain completely necessary? Couldn't we just store the current balances of all addresses, without keeping logs of their transactions as well?

Yes this is called an SPV client.  See this question here for detailed explanation of how SPV works.  There are several of these today, most mobile wallets and the multibit wallet use SPV technology.


what happens to spent bitcoins gained from a block of a soon to be dropped chain as a result of a fork? lets say i gained bitcoins for mining a block and then spent them on a transaction, then later the chain im using gets replaced because of a longer chain. assuming the block difference is up to where i got my spent bitcoins, what will happen to the transactions and coins i gained and spent from mining in my dropped chain?

all coinbase transactions are timelocked from when they are mined, so they are not spendable for a few days i believe. by that time, the block is near impossible to reverse and you can spend the new coins.


How do I register a .bit domain name with Namecoin? I have several namecoins and would like to register a name.  That name could either be for TOR, DNS, or any other purpose.

What are the steps needed to spend these coins?

The algorithm of registering .bit domain is described, for example, on dot-bit wiki.

In short:

Create new domain name with name_new command: ./namecoind name_new d/<name>
Wait 12 or more blocks
Actually register the domain with name_firstupdate, where <rand> is the second (shorter) hexadecimal string returned by name_new, and <json-value> is the domain configuration (similar to DNS record):

./namecoind name_firstupdate d/<name> <rand> '<json-value>'

The basic json-string, mapping the domain to the some IP looks like that:

'{"ip":"1.2.3.4", "tor":"123456.onion"}'

More on domain configuration


What does "P2P peers available. Skipped DNS seeding" means? I'm trying to avoid bitcoin daemon trying to connect to other addresses but the ones that I set in bitcoin.conf.

I've commented vSeeds in chainparams.cpp and I've cleared vFixedSeeds in this way:

        vFixedSeeds = std::vector<SeedSpec6>(pnSeed6_main, pnSeed6_main + ARRAYLEN(pnSeed6_main));
        vFixedSeeds.clear();

But the daemon still tries to connect with some addresses. What I am missing?

What I need to do is to connect two bitcoin daemons that are running in the same machine, with a different genesis block than the main blockchain (both daemons share the same genesis block).

Bitcoin Core does not solely rely on the DNS seeders to find nodes to connect to. The peer discovery system first starts with a local database of known nodes that it gathers after having had connections. DNS seeding or fall back seed nodes are only used if the peers database is empty, i.e. the first time you run the software. So this message means that the peers database is not empty, so it will skip the DNS seeders and go straight to connecting to peers from the database.

  What I need to do is to connect two bitcoin daemons that are running in the same machine, with a different genesis block than the main blockchain (both daemons share the same genesis block).

Use the -connect=<ip>:<port> startup option. This option means that the node will connect only to the specified IP address and port and nothing else; it won't do any other peer discovery.


Merkle tree and data validation If we want to check that data is member of it or not we will take the root, data block, and all the blocks in path between data and root. According to this picture if i want to check that data block, then how can i validate the hash pointer store in above block without having left child?

You are given the hash of the left child itself, and when combined with the computed hash of the data you are given, you can compute the hash of that block (typically referred to as a node). With that hash, you hash it with a provided hash of the left child in it's parent. Then with that node's hash, you hash it with the provided hash of the parent's right child in order to get the root.

If all of the provided hashes for branches that you do not have are correct, and the data is in the merkle tree, then the root hash you end up with will match the root hash that you are given.


Are pseudo-random number generation algorithms good enough to cover all possible Bitcoin addresses? Part of why Bitcoin works is that it's completely unlikely for someone to end up with the same Bitcoin address. But since Bitcoin address generation is based on pseudo-random generation it raises the question: Are pseudo-random number generation algorithms good enough to cover all possible Bitcoin addresses?

See also What happens if your bitcoin client generates an address identical to another person's?

And note that the Android Bitcoin wallet already had an issue with this:
Google patches Android after Bitcoin wallet issue

There are plenty of PRNG algorithms that are good enough. You just run into trouble when you, through ignorance or error, pick one that isn't.

The simplest adequate solution is to gather enough information, from any source and of any size, to ensure that it has at least 160 bits that are unpredictable by any attacker. You can then SHA256 hash this data. You may need to gather a large amount of data to ensure it has sufficient unpredictable bits, but that's okay.

You can make things a bit more secure by hashing many, many times or using a memory hard hashing algorithm. That way, an attacker that can guess some of your bits has to go to much more effort to try random combinations of the ones he can't predict to try to replicate your key.

If you don't have access to sufficient unpredictable data, from any source, then there's not much you can do. Your security is only as good as the unpredictable input your PRNG has.


Slow synchronisation bitcoin-qt - bread wallet I have used bitcoin-qt for a while, but I have read now there is bread wallet for iOS more secure than any OS X wallet, is this true ?

I didn't update it for a while and now it is like 60+weeks behind and it will take a year or so to get it up to date... I made bitcoin transfer to someone on last thursday (4 days ago), it still does not show up, I can see in my log it as payment but with 0/6 confirmations (so I quess I need to update my wallet before transaction going out?)

I installed bread wallet to my iPhone, however I don't know how I can move my bitcoin qt data to it ? Breadwallet asks for recovery code OR new wallet, how I can synch wallets ?

You need to import your bitcoin-qt private key(s) into breadwallet.


Programming a solution to know when a Bitcoin Address has stored a target amount Sorry, I'm probably not going to use the correct terms here.

Does anyone know of, or how to use bitcoind (or of an external library) that can look at or even provide event driven mechanisms to monitor when an address has received equal to or more than a target amount.

I know of the websocket API available from blockchain but I'd ideally do it in house using my own systems if possible.

A rough solution:

If the account is in your wallet, you can use:

bitcoind getreceivedbyaddress "ADDRESS"

to get the amount of bitcoins received by ADDRESS. You can put that line inside an infinite loop. You could create a shell program which stores the result in a variable every 30 seconds (using sleep) and compare it to the previous value. If you subtract the values and find a difference above a threshold you can make the script alert you.

I can be more specific if you tell me your preferences (Python, Linux shell...)


What is the purpose of the "Message" field when sending a Bitcoin Core transaction? I always set the "Label", but what is the "Message" for? I always leave the "Message" empty.
I know that neither is sent over the network; they are just for your own reference. But why both "label" and "message"?

I think it is entirely up to you how to use these fields.
As you noted, the Label and Message are not part of the Bitcoin network protocol, not part of the Bitcoin transaction data or blockchain. But they can be communicated to the other party.
The label and the message are encoded into the QR code that you can generate. So the recipient of the money (sender of goods or services) will see the label and message if they scan a QR code.
The QR code contains text:
bitcoin:address?amount=1.234&label=labeltext&message=messagetext

So, for example, your label could be "order 12345" and the message could be "For delivery between 9 a.m. and 5 p.m."


What is the benefit of upgrading the wallet file? bitcoind -help

displays

-upgradewallet         Upgrade wallet to latest format

I have noticed that my wallet format is a few behind bitcoind's version number. Does this mean it is an old format? If so, why should I upgrade it?

The latest wallet.dat version is 0.6.0; wallet.dat didn't change with the 0.7 releases.

Wallet.dat version 0.4.0 introduced the wallet encryption feature.

Wallet.dat version 0.6.0 introduced 'compressed public keys', which make transactions you send smaller. Right now, that is the only reason you might want to run -upgradewallet, although even if you upgrade, you won't start using compressed public keys until you use up the 100 uncompressed keys in the wallet's keypool. You can force bitcoind to use up the old keys by running the 'getnewaddress' RPC command repeatedly.

Note that when you encrypt a previously unencrypted wallet bitcoind/Bitcoin-Qt will automatically upgrade to the latest wallet.dat version, because it has to re-write the entire wallet.dat file anyway.


How to merged mine with getmemorypool RPC command? The getmemorypool RPC command lists all transactions that are to be included in a block, with the exclusion of the generating transaction. In merged mining, one needs to add an extra transaction containing the hash of a Namecoin block to be generated.

If one uses the source code provided from the Namecoin wiki, how would one merged mine? Is the metmemorypool transaction be supported? Would the special Namecoin transaction be included in the listed transactions?

Most of what you need is explained at https://en.bitcoin.it/wiki/Merged_mining_specification

When you construct the block for the primary chain (e.g. bitcoin) you need to include a merged mining header in the generation transaction (coinbase). The format of this data is explained at the URL above under "Merged mining coinbase".

If, while hashing the primary chain, you get a hash that is below the target for the auxiliary chain (e.g. namecoin) you can create a block on that chain using getmemorypool (assuming the daemon for that chain supports getmemorypool).

To submit a merged mining block, for namecoin you need to do two things that you wouldn't do when mining non-merged.

The first is to set the auxpow bit in the version field of the block header.

BLOCK_VERSION_AUXPOW = (1 << 8)

The second difference is that you insert an auxpow between the header and the transactions. The binary layout of the auxpow is explained at the URL above under "Aux proof-of-work".

The auxpow bit in the version field tells namecoin that after the block header there will be an auxpow before the transactions.

In theory other alt coins may need to have their merged blocks formatted differently and/or submitted differently to their daemon.


can I Re- encryp my wallet with a wallet.dat file from before encryption My computer crashed and I lost access to my bitcoin wallet.. before that happened I knew I had lost my passphrase so when trying to recover my wallet with my wallet.dat I looked for a very early dated wallet.dat and loaded that, when it came up it was not encrypted so I encrypted it.

and made a new passphrase should that bring my wallet back with all the coins with the new encryption

No, it will not bring back any of your coins. The encryption process regenerates all of the private keys in your wallet. Furthermore, the private keys generated are not based on your password in anyway; they are random. So re-encrypting an unencrypted backup will not let you get access to your lost Bitcoin.


Which wallet libraries officially intend to use Bech32 addresses, and will the addresses generated by them be compatible? I use several bitcoin wallets, and I would like to try Bech32 addresses when they come out.

I initially thought to make a GitHub issue for Greenbits, but it seemed more appropriate to just ask such a specific question here:

https://github.com/greenaddress/GreenBits/search?utf8=%E2%9C%93&q=bech32&type=

Everyone's favorite search engine is not exactly forthcoming for this:

https://duckduckgo.com/?q=which+bitcoin+wallets+will+support+bech+32+addresses&t=ha&ia=web

If the answer is "none yet", that's fine, but I'd love to know.

Bech32 is an address format that was only recently proposed. While its design had input from multiple wallet authors, it is way too early to say anything about adoption.

It is important to realize that there is no hurry about this. Every usable address type is available through embedding in P2SH, which is compatible with every wallet created the past few years.

At some point we'll need the higher efficiency and security that native SegWit outputs offer, but that is dependent on SegWit both activating, and being available in both sender and receiver wallets.

Disclaimer: I'm the author of the Bech32 proposal.


Deanonymizing dust attack What is the counter measure against dust attack, in case somebody tries to deanonymize me?

Is there a possibility how to prevent somebody to send you intentional small dust, so that he can track your UTXOs?
I think there is no counter measure to 1. So if 1 already happens, how to deal with this in the most possible clean way and with as little leaked information as possible?

A deanonymizing dust attack works by sending dust to large amounts of addresses. The assumption is that when people send transactions/perform consolidations in the future, dust from multiple addresses will be grouped into a single transaction, thus revealing many addresses controlled by a single entity, since the dust would be swept in a single tx.

(this is somewhat of a simplification, since most parties interested in performing such attacks will also be using other data to group together multiple independent txs).

The best way to prevent against this attack is to:

Never spend dust in a transaction that consumes inputs from addresses that have not previously been linked by a transaction.
Don't spend dust at all.

This will lead to some utxo bloat, but if you are reusing your addresses, you can spend the dust when spending another utxo from the same address. If you are not reusing addresses, simply never spend it.

Some wallets, such as the Samourai Wallet (no affiliation), provide an option to mark dust as unspendable. For systems that you build, you will have to ignore such outputs yourself.


What is P2PK, P2PKH, P2SH, P2WPKH - ELI5 Explain like I'm 5 years old and my other half of the brain is surgically removed :) I don't want to put a lot of stress on my brain

Also what is the difference between BTC held in P2SH and Unspent P2SH Output here?

https://p2sh.info/dashboard/db/home-dashboard?orgId=1

P2PKH: "Pay To Public Key Hash"

This is how transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key and through some cryptographic functions will check if it matches with the public key hash, if it does, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security.

P2PK: "Pay To Public Key"

This is similar to P2PKH; the difference is that it does not conceal your public key. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details.

P2SH: "Pay To Script Hash"

The outputs of a transaction are just scripts that, if are executed with specific parameters, will result in a boolean of true or false. If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.

This can also be used for puzzles like this one.

P2WPKH: "Pay To Witness Public Key Hash"

This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction validity, there is a new part of the transaction called witness where the validity occurs.

  Also what is the difference between BTC held in P2SH and Unspent P2SH Output here?

This means that out of all the P2SH transactions (transactions that can be spent by anyone with a set of parameters [scriptSig] that results in the execution of scriptPubkey with true), the ones with unspent outputs have not been redeemed.

I recommend this video by Andreas Antonopoulos on Bitcoin scripting.


What does it mean if TXID and WTXID are the same? I'm having a tough time understanding what exactly WTXID is and what it means when WTXID and TXID are the same (and vica versa).

What I understand is that WTXID includes the witness data. Since non-segwit transactions do not have the witness segregated, their WTXID should be the same as the TXID. Is that correct?

The wtxid and txid are the same if and only if the transaction does not contain any segwit inputs. The wtxid is the hash of the entire transaction including all segwit data (i.e. the marker and flag bytes and the witness fields themselves). The txid is the hash of the non-segwit parts of the transaction. Because a transaction that does not have any segwit inputs does not have any segwit data at all, both the wtxid and txid hash the same data, so they are the same.


Can someone explain how an HTLC is redeemed? I'm looking at Bolt 3 in the Lightning rfc. My question is about how a HTLC is redeemed. Example HTLC script for reference:

# 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

My understanding is that it can be redeemed in two ways. The first way can be done if the revocation secret is known.

<revocation_sig> <revocationpubkey>

revocationpubkey will produce the correct hash, OP_EQUAL will return "1", the script goes into OP_IF, and the revocation_sig will be valid for OP_CHECKSIG.

The second way involves

<remotehtlcsig> <payment_preimage>

Can someone explain how this satisfies the script? For example, what OP_SWAP does or when it would go through OP_NOTIF/OP_ELSE?

There are three ways in which that offered HTLC output can be redeemed: Revocation using the revocation public key (the example you mentioned), redeemed using a valid payment preimage or back to the local node after the timeout.

Redeemed using a valid pre-image by remote node:

The stack starts at <remotehtlcsig> <payment_preimage>
Since the HASH160 of <payment_preimage> is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now <remotehtlcsig> <payment_preimage> <remote_htlcpubkey>.
OP_SWAP is pushed to the stack, which swaps the top two items on the stack.
Stack is now <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
OP_SIZE 32 OP_EQUAL verifies that the payment_preimage is 32 bytes.
Since the payment_preimage is 32 bytes it will output 1. As a result OP_NOTIF will not be triggered, and hence OP_ELSE statement will be triggered.

OP_NOTIF is triggered is the value on the stack is 0
OP_ELSE is triggered if the preceding OP_IF, OP_NOTIF and OP_ELSE are not executed.

The stack is still <remotehtlcsig> <remote_htlcpubkey> <payment_preimage>
The OP_HASH160 will hash the paymentpreimage. Since payment hash is SHA256 of the payment preimage, we need to hash it with RIPEMD160 so that it is equal to HASH160 of the paymentpreimage.
If the hash matches, then the stack will be <remotehtlcsig> <remote_htlcpubkey> OP_CHECKSIG
If the signature matches the remote_htlcpubkey then 1 will be returned to the stack and this offered HTLC output is successfully spent by the remote node.

Redeemed after time-out by the local node:

To trigger the HTLC timeout condition, the local node will use the witness: 0 <remotehtlcsig> <localhtlcsig> 0
The stack starts at 0 <remotehtlcsig> <localhtlcsig> 0
Since the HASH160 of 0 is not equal to the HASH160 of revocationpubkey, the outer ELSE statement is triggered
<remote_htlcpubkey> is pushed to the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> 0 <remote_htlcpubkey>
OP_SWAP swaps the top two items on the stack. Stack is now: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
Since size of 0 is not 32 bytes it will return 0 on top of stack. This triggers the OP_NOTIF statement. Stack is still: 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 0
OP_DROP drops the top item on the stack which is 0. Stack is now : 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey>
2 is pushed to the stack. Stack is 0 <remotehtlcsig> <localhtlcsig> <remote_htlcpubkey> 2
OP_SWAP swaps the top two items on the stac. Stack is: 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey>
<local_htlcpubkey> 2 OP_CHECKMULTISIG is pushed to the stack. The stack is thus 0 <remotehtlcsig> <localhtlcsig> 2 <remote_htlcpubkey> <local_htlcpubkey> 2 OP_CHECKMULTISIG.
The above is a multisig output which can be spent only with valid signatures from the local and remote keys. These keys are exchanged when adding the HTLC. The output of the above transaction is sent to the local node using a to_self_delay using the time-out transactions.


Why does my Antminer S7 power down right after startup? Before asking the question I'll better introduce what I am doing:

I have:

Antminer S7 (Bought from BitMain)
BitMain PSU (Bought from BitMain)
220V & 10-16A & 3*0.75mm^2  Power Cord for the PSU
A DAIYO laptop power protector which supports 10-16A & 250V

Yesterday, I received my Antminer S7, so when I had connected the PCI pins I connected the PSU's power cord with the laptop power adapter.

The result looked like this:

Then the Antminer powered up with variable fan speed. I connected the network cable and when I was going to my PC to configure the Antminer it just powered off. I am not sure which one powered off first, the PSU or the Antminer but they both had turned off.

I ran to unplug the Power Cord (It was very hot), so I thought that the power cord may have burned. To test that I connected it to my computer's psu and my computer didn't power up. So I think that it was burned, but 30min later my father tested it again and this time my computer powered up.

Can you tell me what the problem could be?
What made my Antminer to turn off automatically?
Someone told me I should have used a 3*1.5mm^2 Power Cord, is that the answer?
Could the Antminer have been damaged?

I'm guessing that the PSU kicked off from the overload circuit protection.  I don't have this miner nor do I use 250V setup.  However from observation your equipment setup appears correct.  Could you try just the psu by itself?  Leave it on for maybe 5 minutes - nothing should happen and the cord should remain cool.  Was the cord itself really hot or was the adaptor on the wall hot too?  The miner should be okay (if it's not defective) I don't recall having antminer equipment that shut off, but if your wiring is really hot then consider buying lower gage wire (thicker) - though at this point I would also consider putting the surge protector between the pc and see if that seems to continue to work (though if all those things seem to pass then consider trying it one last time) It could be built in overload protection on the PSU kicking in as well, if it overloads and turns off on the 2nd round then you should try to get bitmain involved as you never even got the chance to use the device - maybe the surge protection is also a factor here though so perhaps try it without that...I mean that seems unlikely, but try to rule out pieces if you can while testing (unless its dangerous to do so)


How are brain wallets generated? How do sites like blockchain.info and bitaddress.org generate private keys by simply hashing a string? (the passphrase?)

In this wiki article,
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
Step "0" starts with an ECDSA key pair already generated.

Does this mean that any 256-bit value can be a valid ECDSA private key? So wherever I am in the world, I can always just SHA256(passphrase) and get my private key?

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

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


Spending UTXO from same block Block 546 is the first time a (actually two) transaction spends the UTXO of a transaction from the same block.

Is the order important? (The transaction that generates the UTXO has to appear before in the block than the transaction that spends it)

Is it still possible today?

The order must be causal. Most blocks today have outputs that were created earlier in the block.


Can I use opcodes traditionally used for verifying keys to verify payment sizes? Can I use binary opcodes usually used for verifying keys to verify payment sizes?

It looks like these opcodes like OP_EQUALVERIFY and OP_NUMEQUALVERIFY are used for checking signatures or keys, rather than bitcoin amounts.

Example:

For an example use case, say my brother and I run a partnership, and all Bitcoin payments to our invoices go to a specific address.

The client would pay their invoice to a P2SH address, but any further spending from that invoice would have to go to my brother and I equally.

Conditions:

I want to lock outputs for a given input such that:

The bitcoin input can only be spent to two specific outputs*, my brother's address and mine
The amounts paid to these specific outputs must equal each other

*aside from change addresses

In the example above, could I use OP_NUMEQUALVERIFY or even the non-binary operator OP_GREATERTHANOREQUAL enforce that any client income was paid to me in an equal or greater amount than my brother?

This isn't possible.

You can use those arithmetic operators to compare any numerical values that you can get onto the stack - they are not inherently restricted to signatures and keys. But you would have to get the relevant data (output addresses, output amounts) onto the stack in the first place, and there is no opcode  to do that.   The script doesn't get to see that information, so you can't  restrict the spending of a transaction in such ways.

Related: Can an account define conditional tags to blockchain


Bitcoin node Decentralization Is the number of independently owned and operated full Bitcoin nodes more important than the total number of full Bitcoin nodes with regards to Decentralization?

Assuming the answer to the above question is yes:

How can the number of independently owned and operated nodes be counted and verified?
Is there an answer to question 1 above that would not violate the privacy of the nodes owner/operator?

Yes, independently operated nodes help decentralization more than the same number of nodes operated by a single entity.  That's basically the definition of "decentralization" in this context.  That is not to say that a single organization running multiple full nodes does not add to overall network health, since those nodes still participate in relaying transactions and providing historical blocks.

As for your other questions:

It is very difficult, if not impossible, to identify which nodes are run by which organization.  Nodes are often run using proxies/TOR to obscure their true IP addresses, which is often the only way to determine ownership.  If we don't know which nodes are run by whom, we cannot correlate which nodes are run by the same entities.
Without a solid answer to question 1, I don't think there is a good answer to question 2 either.

You could assume that organizations running multiple nodes will broadcast or relay transactions from all their nodes simultaneously.  If so, then you could figure out which nodes are a part of which group by having many nodes on the network, yourself. Then you could correlate which nodes first relayed which transactions.  However, the initial assumption is bad, and adequate tracking would require you to have a large number of nodes on the network.  I don't think your results could be trusted enough to be worth the effort.

In a permissionless system such as Bitcoin, it is intentionally hard for anyone to know that much about the other participants.


Why is a blockchain often compared to a linked list? I often hear people say that a blockchain is essentially a linked list (i.e. https://www.quora.com/Is-a-blockchain-essentially-a-linked-list)

A block stores the hash of the previous block for validation/consensus. This is similar to how a node in a linked list references the address of the previous node, but it's not quite the same.

In a block, the previous hash is stored by value, not by reference, so you can't really access the previous node by traversing the chain. Whereas in a linked list, you store the address which is a reference to the previous node. You can access any block in constant time where as in a linked list, it's linear time.

On top of this, many implementation that I've seen of a blockchain is an array/slice of blocks. I tried briefly looking at bitcoin's source code (disclaimer: I don't know C++). It looks like the implementation of the chain of blocks in memory uses std::vector which is basically a dynamic array.

Isn't a blockchain more similar to an array than it is to a linked list?

I assume the linked list analogy just arises because of the reference to the previous block as you say. It's less about how to find that block, and more just about identifying it. The actual data structure used to store the Blockchain isn't what is being described.


How to add bitcoins in my wallet? I'm new to this BTC world, one day someone offered me to pay using BTC and made me create a wallet on https://multibit.org

I recently used it to pay for something online, and another transaction and another one ...

Now, my wallet is almost empty and I need more BTC to make more purchase so the question is : How to add bitcoins in my wallet ? *would like to use my credit card

There's only send/receive options in there :)

Thanks for showing me the way

Without knowing what country you are in it's hard to answer fully.

But, as Nick said, you can use Circle to purchase Bitcoins for USD using a credit card.

To further elaborate, Bitcoins are a currency, so the only real way to get them is either Mining, Faucets, or by converting your government currency into Bitcoin using an Exchange.


How to monitor the blockchain for new blocks I want to scan new transactions as they are added to the block chain.

Does anyone have a suggestion on how to do this. Are there any APIs that allow for this? Or is there a way to directly tap into the bitcoin network with ruby?

Full disclosure, I'm BlockCypher's Developer Advocate. We have both a WebSockets/WebHooks API for unconfirmed transactions, which you can read about here, along with a Ruby example: http://dev.blockcypher.com/?ruby#using-webhooks .

But if you wanted to run a local implementation that's primarily Ruby-based, you could try Coinbase's Toshi, or bitcoin-ruby:

https://github.com/coinbase/toshi
https://github.com/lian/bitcoin-ruby


Who are Alice and Bob? Simply: who are Alice and Bob, and why are they mentioned in every Bitcoin-related article I read about that talks about Bitcoin transactions?
What is the history or mystery of these two?

Fictional characters. Cryptography (and other) books use names like that often.

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


Set up a Bitcoin full node: static or dynamic IP address? I am trying to set up a new Bitcoin full node and my institution ISP is trying hard to not give me a static IP address for this purpose. I guess because of the concern that the node will be DDoSed, port scanned, etc.
My questions are:

How frequently a full node with static IP get DDoSed?
Is there any strong reason for favoring static IP address over dynamic IP address?

How frequently a full node with static IP get DDoSed?

It depends on who owns the full node, and whether the owner of a full node is known. A full node by itself is unlikely to be DDoS'd since there is little point in attacking any random node. However, if the node is owned by, say, an exchange and it is known that the node is owned by the exchange, it might be DDoS'd as attacking that node may result in some gain for the attacker. But in general, full nodes don't get DDoS'd because there's no point.

  Is there any strong reason for favoring static IP address over dynamic IP address?

Connections that peers make to you are based upon the IP address. They remember the IP addresses of other nodes and try to reconnect to them later if they go offline. With a static IP address, it is more likely that your node will get connections because it will have been at the same IP address for a while and nodes have remembered it. Static IP has no effect on your outbound connections (which, to your node, are the most important, not the inbound ones).


How to use bitcoinjs-lib with Regtest? I was trying to use the bitcoinjs-lib (1) with my regtest network. More specifically I was trying to build a tx with TransactionBuilder but it gave me a 'transaction has no matching Script' exception.

In a closed github issue (2) I find out that it's possible to specify the network (network.testnet), but I can't find any documentation related to regtest. I just want to create and broadcast a raw tx created with bitcoinjs to my regtest network.

So, has anyone talked to a regtest network with bitcoinjs-lib successfully? If not, what other libs would you recommend for the satoshi client? Thanks.

(1) https://github.com/bitcoinjs/bitcoinjs-lib

(2) https://github.com/bitcoinjs/bitcoinjs-lib/issues/500

Oops! Noob mistake.

I thought that testnet and regtest had different version prefixes (not compatible) but they are (the bitcoin wiki and bitcoin developers page doesn't clarify this, though). So I went into a npm package that added dogecoin and litecoin testnets compatibility with bitcoinjs-lib (it's called bitcoinjs-testnets).

But the solution in the second Github link that I posted works.

Here I repost the text:

  Just want to give some feedback that may help new users in the future.
  I lost a lot of time debugging an issue that is probably extremely
  obvious to some, but it was not directly obvious to me.

var bitcoin = require("bitcoinjs-lib");
var keyPair = bitcoin.ECPair.fromWIF("mywif", bitcoin.networks.testnet);
var txb = new bitcoin.TransactionBuilder(); txb.addOutput("myaddress", satoshis);  // <---- this will fail with "has no matching Script"

  Because of the error message I came to the conclusion that I was doing
  something fundamentally wrong creating the transaction. In the end, it
  turns out I just needed

var txb = new bitcoin.TransactionBuilder(bitcoin.networks.testnet);

  Feel free to close this, just wanted to share my experience

I wish my noob experience has helped you! (pardon for my english).


How do miners handle transactions when a different miner creates a new block? If all transactions are broadcast to all nodes, and all nodes are mining these transactions into blocks.  When a block is created and the block is broadcast to all nodes, it may contain transactions that other nodes are currently trying to put into their blocks.....what happens in this scenario?

Not all blocks are mining the same transactions in their respective proofs-of-work. Each miner collects enough transactions via gossip until they reach the block size limit. Not all transactions will make it into a certain block, so those will be more likely candidates to make it into the next block. Miners decide which transactions to include in a block with the following equation:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes


How to find details about very first block mined for any crypto? Hi is there any resource or site where we can see details of the very first block mined like its time-stamp and other details . I have been asking around in groups for last 3 days no answer .

I did find some details about bitcoin but would like to find for other crypto coins too.

If you have an altcoin's node software and that software is based off of Bitcoin Core, then you can use the following RPC commands to get information about the genesis block:

getblockhash 0

This will get you the hash of the genesis block. Take that hash and do

getblock <hash>

This will give you all of the information about the genesis block.


BCH to BTC in same Trezor wallet I changed BCH in my Trezor to BTC using the wallet coin splitting tool and sent it back again to the same wallet using a new BTC receive address rather than another external wallet like eg Electrum using Shapeshift exchange. But the BTC didn't arrive. Have I lost the coins or are they just lurking in cyberspace waiting to be found again ?

If you sent BCH to your Trezor BTC address or vice versa, you can use https://trezor.io/recover-coins/ to recover your coins.  The only exception is if you send BCH to a BTC 3... address (segwit), since these are not supported by Bitcoin Cash.

To convert BCH into BTC or vice versa you need to use an exchange.


Trying to understand how bitcore-node stores the data in the DB I'm looking into the data and source of bitcore-node ( http://bitcore.io/ ), I'm a bit confused how all the information is stored in the database, probably it's in a similar way to others block explorers, so maybe someone could help me.

In this case for example https://blockchain.info/tx/acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42

In the database I found two txo- txo-acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42-0

{"prevTxId":"8697331c3124c8a4cf2f43afb5732374ea13769e42f10aa3a98148a08989af5e","outputIndex":1,"sequenceNumber":4294967295,"script":"4730440220106c316c22d4bf8c970f8e4b1af1edd95121397cfe29ab987cb000b478ec8e4302202b77986b89d77ab716da3cf53424efacf35e9097b1c89194df220e99503b8cae01","scriptString":"71 0x30440220106c316c22d4bf8c970f8e4b1af1edd95121397cfe29ab987cb000b478ec8e4302202b77986b89d77ab716da3cf53424efacf35e9097b1c89194df220e99503b8cae01","heightConfirmed":37514}

txo-acb2e895a9b3664cfcfb13dd0321ef0c1205cf2aa082681dc6ba424af6456a42-1

{"satoshis":10100000000,"script":"76a91427d25a1ff9a6da31eeb991c48bb6cd95191a6b2c88ac"}

Clearly different data, not sure why in one case we store the previous txid and in the other just the satoshis sent. It has to be obvious, but not sure what I'm missing here.

Another example https://blockchain.info/tx/00eff263871e6d44abed66d90abb10d5a211441668511dba3146e380360efe4b

txo-00eff263871e6d44abed66d90abb10d5a211441668511dba3146e380360efe4b-0 (from 0 to 5 all have similar data)

{"prevTxId":"6aebb4a764a027436f703ca9d42d0735423798f56973f9f236832a91fc2e9026","outputIndex":0,"sequenceNumber":4294967295,"script":"473044022057801e812f964bcb9e8ff17b37acef55afbb7119a66f24a148ba65e86a7aa1e3022064af657d280068b979ea17a29969976aedee8a664b3f1b575ebb88ef9275302601","scriptString":"71 0x3044022057801e812f964bcb9e8ff17b37acef55afbb7119a66f24a148ba65e86a7aa1e3022064af657d280068b979ea17a29969976aedee8a664b3f1b575ebb88ef9275302601","heightConfirmed":10712}

Also,... they are inputs, not outputs of the transaction.

I'm trying to read the code, but I can't get to understand all the pieces.

As someone points me in reddit, it looks like it's using txo-- to store both, outputs and inputs. So I'm not sure how bitcore manages to get the inputs/outputs separately later (the API allows you to request only the inputs for example).

Bitpay's bitcore-node project uses the same datadirectory as Bitcoin Core. You can see this in their sample configuration in their README:

var configuration = {
    datadir: '~/.bitcoin',
    network: 'testnet'
};

As such, the you can see: What are the keys used in the blockchain levelDB (ie what are the key:value pairs)? for information on what is in this database. However, bitcore-node does provide another interface for storing extra data about addresses and their balances. This is defined in this file. You have to enable this in your configuration and re-index the blockchain to enable this module, as their README details.

As these lines show, for each output, key-value pairs are added to the leveldb database in this format:

key:   [AddressModule.PREFIXES.OUTPUTS, address, timestamp, txid, outputIndex].join('-'),
value: [output.satoshis, script, height].join(':')

And, similarly for inputs, this is the format of the key-value pairs:

key: [AddressModule.PREFIXES.SPENTS, input.prevTxId, input.outputIndex].join('-'),
value: [txid, j].join(':')


How can OP_CHECKLOCKTIMEVERIFY be used to create outputs provably spendable by anyone? While reading BIP 65 it says that op_checklocktimeverify can be used to create provably spendable outputs by anyone. How is this possible?

Start by reading the whole sentence:

  CHECKLOCKTIMEVERIFY can be used to create outputs that are provably spendable by anyone (thus to mining fees assuming miners behave optimally and rationally) but only at a time sufficiently far into the future that large miners can't profitably sell the sacrifices at a discount.

In other words, CLTV is used to delay when an output can be spent, not to make it provably spendable by anyone. The latter is trivial: just don't have any signature checking operations in a script.


Any wallet that support cancellation of transaction? Does anyone know what free bitcoin wallet can support the cancellation of unconfirmed transactions?

Yes. Most software wallets will have this feature. It's called double spending with a higher fee.

There is not really a thing as "cancelling" a transaction, once it is broadcasted, it is unstoppable, unless you double-spend it. (The first tx will get cancelled)


Are there any API servers available for alt-coins that allow for transactions to be broadcast into their networks? With blockchain.info we have the pushtx API that allow one to broadcast raw transactions into the network. It appears to be one of few services that offer such functionality. Are there any servers that offer such APIs for altcoins, or does one need to create their own / run their own version of altcoin'd to have access to such functionality?

I have written a program in python that does exactly this for Litecoin, Bitcoin, and Dogecoin. The program can connect to peers on any of the above mentioned crypto network and submit the transaction directly instead of relying on a third party central server to push the transaction out to the network.

It is available open source under https://github.com/kaykurokawa/pushtx


What happens if my wallet gets "hacked" and my BTC is stolen? What if my wallet gets hacked and the hacker transfers all BTC to his account?
Is there is any way to get it back, or to open a dispute to specific address or anything else?

All BTC transfers are final. If a hacker moved your BTC elsewhere, you can't get it back.

You have to keep your funds safe. See https://en.bitcoin.it/wiki/Securing_your_wallet.


lightning to lightning non custodial swaps Do you know the way to freeze funds in lightning tx to implement atomic swap between two independent lightning networks?

An HTLC always "freezes" funds. It is a smart contract that says "here is the balance and a hash. If you give me the preimage of that hash within time T, the balance is yours. Otherwise I can take it back.".

You can then use this functionality to achieve an atomic swap by going through a service node that is active in both networks and offers to swap currencies. Just route a payment from yourself to yourself via the swap service node, starting with currency X and ending with currency Y, switching currencies at the service node using the offered exchange rate.

Like every LN payment, this is trustless because it is atomic: Either all transfers take place or none. However, note that there is a free american option given to the service node here: For the time T, it can stall and observe the spot market and only do the trade if the exchange rate moves favorably for him, or otherwise just let it time out. This is why using LN for currency exchange might not be economically wise.


Bitcoind -walletnotify more than 6 confirmations? I've configured bitcoind -walletnotify to run php script when callback is triggered. It works fine, but only notify until 3 confirmations are received. My goal is to notify when 6 confirmations are received for that transaction. Is there a way to configure it to notify until 6 confirmations?

The Bitcoin Core -walletnotify should only run at most twice for a typical transaction:

When the transaction enters the local node's mempool
When a block arrives containing that transaction.

I haven't tested this, but it looks like the code may also send a notify if the transaction is conflicted, if it is no longer confirmed after a reorg, or when it is confirmed by a different block after a reorg.

But that means you should only be notified until 1 confirmation, not 3 as you say in your question.

There is no setting that lets you choose when you get notified.  However, you can build this feature for yourself using a -blocknotify command that calls one of the RPCs, such as listtransactions.  Then you can check the confirmations field for each transaction and trigger an action if it's greater than or equal to 6.

You can alternatively use the listsinceblock RPC to list all transactions in the wallet that aren't part of the fifth most recently confirmed block or an earlier block.  (That is, transactions that don't yet have six confirmations.)


Bitcoin Core wallet update schedule and transaction 1) Currently I have Bitcoin Core QT for MS windows 64bit - 32bit version 0.11.2 (yellow one with the most porpularity). Is there any scheduled update of QT to higher version in a near future?

2) I heard from someone that if the Bitcoin Core wallet (same as the above. MS windows 64 bit- 32 bit in yellow color) for each of owner is NOT the same (i.e one has 0.11.0 ver and other has 0.11.2) and receiver's wallet is not synchronized with BTC P2P network, sending BTC from one wallet to other is not feasible and lost permanently. Is this true?

Different versions of the Bitcoin-qt wallets can most certainly send and receive bitcoins from each other. They are compatible. And it looks like it will stay compatible for the foreseeable future as no hard forks are planned near term.

Just make sure you use the "official" client from bitcoin.org and check signatures to make sure you get the correct one. Also try things with small amounts of money to make yourself comfortable with how it works.

All the other wallets mentioned at bitcoin.org are also compatible regarding sending and receiving bitcoins by the way, but I'm assuming you're interested in running a full node i.e. bitcoin-qt.

Note that this site is not affiliated with bitcoin.org or the core developers (although some of them post here sometimes). I'll clean up your question to better fit the purpose of this website. One way to contact core developers is through the #bitcoin IRC channel.


Key derivation in HD wallets using the extended private key vs hardened derivation I am reading the book Mastering Bitcoin and confused about wallet key derivations in Chapter 4. Keys, Addresses, Wallets.

The book first mentions a private child key derivation where the child private key is derived from three inputs: (parent public key previously derived from parent private key, parent chain code, index).

Next, the book discusses extended keys and mentions two types: extended private keys and extended public keys.

The extended public keys are used to derive children public keys from parents public keys to avoid exposing the private keys, hence more secure. This is the block diagram for the extended public key.

On the other hand, the book mentions that the extended private key is used to derive a child's private key using the parent's private key and chain code.

However, although the extended public key does not expose the private key, it is still risky to use since it exposes the chain codes. If a private key is leaked, they can be used together to derive other children key.

Finally, the book suggest to use the hardened key, which to me is exactly the same description as the extended private key.

My question first question is, is the extended private key the same thing as the hardened key derivation?

My second question is, which technique is actually used when deriving the private key for children, the first one I mention in my question or the second one using the extended private key which to me is the same exact thing as the hardened key derivation.

There's a lot of confusion here, mostly bits and pieces of the whole scheme that is Hierarchical Deterministic derivation, and finally two questions that seem to indicate missing some point about it.
The answer to the first question is No.  The second question is more interesting :

Let's start from extended keys, specifically BIP32 keys.
Like private keys and public keys, extended keys can be either "private" or "public".  I put both in quotes becaus both types of extended keys do contain private information.
At least enough to track key use. This mechanism is used by hardware wallets and "watchonly" software wallets on a PC.

An extended key is just a base58 encoded serialization of a few pieces of data :

[ magic ][ depth ][ parent fingerprint ][ key index ][ chain code ][ key ]

Where key can be either a public key or a private key.  Private keys are prepended with a single 0x00 byte, so the length of this blob stays the same.
An extended key is usually derived by "traversing" some path, meaning you would start your derivation at some parent extended key, and consecutively derive child keys with specific indexes until you finally derive the final extended key in the path.
I'll stop using "extended" in this answer.  From now on I'll refer to an extended private key as xprv and to an extended public key as xpub, and just "keys" sometimes.  Non-extended are just "private key" or "public key".

An xprv or xpub's magic are 4 bytes to indicate the network it belongs to: testnet or mainnet (t or x respectively), and the type of key it is (pub and prv respectively).
The depth is a byte that indecates how deep an xpriv or xpout is in a path, starting from 00 as the depth of the master key, and incremented by one as the derivation of more child keys is done along the path.
Note that up until now, the only difference between xprv and xpub keys that I mentioned is the prv or pub part in the magic.
It also should be clear that an xprv and xpub can be in the same path, and in the same depth.  This means that for such pair of xprv and xpub, the [ key ] part of the will have a 32 byte private key (prepended with one 00 byte) in the xprv, and a 33 byte public key which is the public key which which you get from the private key in the xprv.

A parent's fingerprint are the first 4 bytes of the hash160 of the public key of the parent.  This means that even if a parent xprv was used to derive a child xprv, it would have the same parent fingerprint as if a parent xpub was used to derive a child xpub.
A parent-child relationship between keys means that they are adjacent in a path.

A path is an n-tuple of indexes, usually in base 10, separated by /.  The range of an index can be between zero and and 4294967295 (or 2^32-1), where anything in [0,2147483647] follows non-hardnened derivation, and indexes in [2147483648,4294967295] follow hardened derivation.
You can see that each half of the range of indexes is used for a different method.  We can say that there are two ranges.  [0,2147483647] for non-hardened keys, and [0h,2147483647h] for hardened keys.  The h indicates that the index (we'll call it i) should be treated as i + 2147483648.
You're probably more likely to see the h notation as a caret ' instead, so 1' == 1h, but I don't think it's very pretty so I'll stick with h for now.

An example of what a path looks like is :

m/0h/1/2h/2/1000000000

The m means that the key at this index is a master xprv or master xpub.  A small m means that this extended key is a master xprv, and big M a master xpub.  Following the previous definitions, you can tell that m is the parent of the key at 0h, and the key at 2h is the child of the key before it at index 1.
To make this easier to follow, we'll annote the different keys in the path with letters {a..e} if we mean that these are xprvs and {A..B} if xpubs.

m / 0h / 1 / 2h / 2 / 1000000000
m   a    b   c    d   e

A path is usually given with indexes in base10, but in the key itself they are encoded in hex (base16), so a [ key index ] is always 4 bytes with zeros prepended if needed.  The depth and index of a master key are both alwasy zero, so 00 and 00000000, and they can get to a maximum of FF and FFFFFFFF respectively.
So m and a are parent and child, and so are d and e.  The depth of b is 02 and its index is 00000001, and the depth of c is 03 while its index is 80000002 (80000000 + 2).
The last child key to be derived is e.  We can say that we followed a path starting at m, from it we derived the key a at index 0h, then from a we derived the key b at index 1.. and so on.  But what does it mean to derive a new key?

The remaining two elements in the extended key format, the parent's [ chain code ] and [ key ] are used together with what would be the child key's index to derive it.
That means that to derive c from b, we'd feed some function with b's chain code and key, and c's index.
A specific example of our b and c would be :

b :

0488ADE4
02
5C1BD648
00000001
2A7857631386BA23DACAC34180DD1983734E444FDBF774041578E9B6ADB37C19
003C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC93368

c :

0488ADE4
03
BEF5A2F9
80000002
04466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F
00CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA

The fields are ordered as in the structure above.  On both, the magic says xprv, the depth is incremented between the parent and child, the fingerprint at c is the hash160 of the public key that you would get from the private key at b, and b's index is in the first, non-hardened half of the range while c's is the second, hardned half.  Finally the chain code and keys of each of the xprvs are encoded.

Deriving the chain code and key for c from b is done with a process called CKDpriv, which means deriving a child xprv from a parent xprv.  In this process we used the chain code and key from b, and the index from c.
The important point to make: We only encoded c after deriving its chain code and key from what would be its index.

Any xprv can be used with CKDpriv to derive a child xprv at any index.  The specific way CKDpriv will act on the input depends on the child's index being in the hardened range, or the non-hardned range.  Basically, a CKDpriv function runs an HMAC-SHA512 on the parent's chain code and key, and the child's index.  This hmac function takes two values a key* (not to be confused with our occurences of key, will be refered to as hkey), and text.
The parent's chain code is used as the hkey, while the text is made up of the parent's key in the private key form if the the child's index is in the hardened range, [0h,2147483647h], and in the public key form if the index is in the non-hardened range.  It is then concatenated with the child's index.

c's index is in the hardened range, so CKDpriv's hmac-sha512 runs with the inputs:

HMAC-SHA512( 2A7857631386BA23DACAC34180DD1983734E444FDBF774041578E9B6ADB37C19,
             003C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC9336880000002 )

Which returns a 64 byte hash :

8F6154A0A82D0F68B9E5B586EA66D951DAAA071BEBD390097CC516285C791A6204466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F

The 32 bytes on the right half of this hash, 04466B9C...C7B1503F become the child's (c here) chain code, and the 32 bytes on the left are used to "tweak", meaning just "addition mod n" to the parent's key, in this example :

  8F6154A0A82D0F68B9E5B586EA66D951DAAA071BEBD390097CC516285C791A62
+
  3C6CB8D0F6A264C91EA8B5030FADAA8E538B020F0A387421A12DE9319DC93368
=
  CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA   mod n

I didn't write the 00 prepended bytes in the keys here because this is just adding numbers, but those zero bytes are very important for the hash function, so I purposely included them there.

Now that we've got c's chain code and key (in private key form), we would want to actually encode c for it to be a usable xprv.
To get the fingerprint from b, we need to know the public key of the key from b.  Since it's in private key form, we'll have to do multiplication:

CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA * G
= 03501E454BF00751F24B1B489AA925215D66AF2234E3891C3B21A52BEDB3CD711C

Take the hash160 of this public key, and the returned hash is BEF5A2F9A56A94AAB12459F72AD9CF8CF19C7BBE.
The first four bytes are b's fingerprint : BEF5A2F9.
Encoding the rest of c is easy.  Start with the magic xprv since we derived a child xprv, increment the depth of b by one, then the fingerprint.
Next c's index is encoded.  We derived index 2h, so this would be 80000002, and then the new chain code and key that we got from CKDpriv.

This is basically what hardened derivation is.  The parent's private key and chain code are used to derive the child key at some hardened index.
What if we want to derive d?  It's at index 2, so a non-hardened index.  This is the second case of CKDpriv.

The difference is in what is used for the text parameter of the HMAC-SHA512 function.  Instead of using the parent's key in private key form, we use the public key form, so to derive d at index 2 from c, we first find the public key of c :

CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA * G
= 0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC2

Then continue following the same steps as the above:

HMAC-SHA512( 04466B9CC8E161E966409CA52986C584F07E9DC81F735DB683C3FF6EC7B1503F,
             0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC200000002 )

                            tweak                                                            chain code
437984D45C4A2F5840C65B3DC6D7274E2859AD25D092DB032C49AA4D006A426B|CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD

* note that 00 is not prepended to the text, since this is a public key.

  437984D45C4A2F5840C65B3DC6D7274E2859AD25D092DB032C49AA4D006A426B
+
  CBCE0D719ECF7431D88E6A89FA1483E02E35092AF60C042B1DF2FF59FA424DCA
=
  0F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4   mod n

hash160( 0357BFE1E341D01C69FE5654309956CBEA516822FBA8A601743A012A7896EE8DC2 )

finger
   print
EE7AB90C|DE56A8C0E2BB086AC49748B8DB9DCE72

The rest is easy, and we can encode :

d :

0488ADE4
04
EE7AB90C
00000002
CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD
000F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4

The difference between these two methods of deriving child xprvs is subtle but important.  It enables CKDpub, which is a function to derive child xpubs from a parent xpub.  CKDpub works almost the same as CKDpriv's non-hardened derivation, but it does the derivation using point addition,  so rather than adding up integers to make child private keys, we're adding up points to make child public keys.
Notice how in the non-hardened derivation we used the parent's public point for the HMAC-SHA512, we used the tweak as the added value to the parent private key to derive the child private key, specifically, we derived d's private key.

To understand CKDpub, it helps to first know about yet another BIP32 function called Neuter.  It's purpose is to convert an xprv to an xpub.
Let's "run" Neuter on our xprv d.  We'll call the resulting xpub D.  Neuter does two things to an xprv:
1. Replace the magic from 0488ADE4 to 0488B21E (replaces xprv with xpub)
2. Replaces the private key in the key field` with the public point of the same private key

for our xprv d, the public point is:

0F479245FB19A38A1954C5C7C0EBAB2F9BDFD96A17563EF28A6A4B1A2A764EF4 * G
= 02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29

(this is just normal process of private key -> public key)

so the result is:

D:

0488B21E
04
EE7AB90C
00000002
CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD
02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29

Now d is "neutered", D has the public key encoded, but see how the chain code, depth, fingerprint and index persisted.  The xpub D is at the same position in the path as the xprv d.  We will be using the chain code and key (public key) for CKDpub, same as CKDpriv with non-hardened derivation, but as for CKDpriv, we derived the child private key using:

tweak + (parent private key) = child private key

for CKDpub we will be using:

tweak*G + (parent public key) = child public key

This works because parent public key is really just (parent private key)*G, and child public key is just (child private key)*G.  That is, if we take the CKDpriv tweak equation and multiply all elements by G, we get exactly the CKDpub tweak equation.
CKDpub can only derive child xpub keys in the non-hardened index range.  This is because the information present in the parent xpub, specifically the public key in the [ key ], only applies to the non-hardened range.
Where in CKDpriv we could use the private key to know the public key, we can't go the other way.  the HMAC-SHA512 round that uses public keys in CKDpriv applies to the non-hardened index range.

Now that we have neutered d to create the xpub D, next in the path is e's with index 1000000000 (or 3B9ACA00), which is in the non-hardened range, so we should be able to derive E the child xpub from D using CKDpub.  We start with hmac-sha512 of the parent chain code as hkey and parent key (public key) concatenated with the child E's index :

HMAC-SHA512( CFB71883F01676F587D023CC53A35BC7F88F724B1F8C2892AC1275AC822A3EDD,
             02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D293B9ACA00 )

                            tweak                                                            chain code
37D3E49D8ECB854CC518BBA096F46795A9707860BF0FC95E5B19278C997098D4|C783E67B921D2BEB8F6B389CC646D7263B4145701DADD2161548A8B078E65E9E

Multiply the tweak by the generator G so we can tweak the parent's public key using point addition :

37D3E49D8ECB854CC518BBA096F46795A9707860BF0FC95E5B19278C997098D4 * G
= 0327E992F68217BC3E88CFFC3FEAB475880145413CBE008DB22B496DF4E1C3F864  <- tweak*G

Add the tweak to the parent point.  The result is the child's public key :

  0327E992F68217BC3E88CFFC3FEAB475880145413CBE008DB22B496DF4E1C3F864
+
  02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29
=
  022A471424DA5E657499D1FF51CB43C47481A03B1E77F951FE64CEC9F5A48F7011

Get the paren'ts fingerprint :

hash160(02E8445082A72F29B75CA48748A914DF60622A609CACFCE8ED0E35804560741D29) = D880D7D8....

Finally we can encode E :

0488B21E
05
D880D7D8
3B9ACA00
C783E67B921D2BEB8F6B389CC646D7263B4145701DADD2161548A8B078E65E9E
022A471424DA5E657499D1FF51CB43C47481A03B1E77F951FE64CEC9F5A48F7011

Neutering d to make D then deriving E, we can say that our path now looks like :

m / 0h / 1 / 2h / 2 / 1000000000
m / a  / b / c  / D / E

Or we can use the N() notation (for Neuter) to show where CKDpub was used, but I think it's less pretty.
m / a  / b / c  / N(d / e)

So to recap on your question, there are 3 different derivation methods, two using private keys and one using public keys :

CKDpriv to derive a child xprv at a hardened index
CKDpriv to derive a child xprv at a non-hardend index
CKDpub to derive a child xpub at a non-hardened index