Mapping the Bitcoin Lightning Network: Why not use the Blockchain? Researching about the available routing algorithms for the Bitcoin Lightning Network, I have been reading the Flare whitepaper, and this idea/question came to mind:

Since all payment channels are created with a blockchain transaction, and Flare itself checks the Blockchain to see if a channel is live or has been closed, wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?

Do/can on-chain transactions that create the payment channel store nodes' ids? If yes, then this seems a trivial and maybe effective tactic.

wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?

No because it is not possible to know which transactions are related to a payment channel opening, and channel closing transactions can be ambiguous. The funding transaction sends money to a 2-of-2 multisig, but these are in outputs as a P2WSH or P2SH-P2WSH script which means that the redeemScript that specifies the 2-of-2 are not known. You cannot assume that any P2WSH or P2SH (because a P2SH-P2WSH looks just like a P2SH) is for funding a payment channel.

For closing transactions, if there is a cooperative close, then the spend of the funding transaction's outputs will look just like a normal 2-of-2 multisig, which is not indicative of a payment channel. In a unliateral close, you would be able to identify the unilateral close only after the person closing the channel spends their output.


What is the different between full-index client to full node? I've read in "Mastering bitcoin" that a wallet can construct a transaction even if offline but is full-index client, I know full node is a client which holds the complete blockchain data.
is there a different between the two ?
Another question is how do I know I'm running full node? does 40giga of data in the data folder is my confirmation of running full node and having the complete blockchain on the HD ?

"Full-index client" is a term really coined by the author. I've never heard of it in the Bitcoin community. After reading the section in the book, it seems that a full-index client is just a client that holds all the data in the blockchain but is not necessarily a full node. To be a full node you must adhere with all of the bitcoin protocol. A full-index client might not adhere with the entire bitcoin protocol, but would still have the entire blockchain. Full-index simply means "holds all the data", but it might not be a full node. At least that's my interpretation.

To run a full node you must download Bitcoin Core, which is the only supported "full node" I am aware of.


Will mining Bitcoin slow or stop other computers on my home network? Will mining Bitcoin slow or stop other computers on my home network? My son wants to set up a computer to mine Bitcoin but I have a daughter that attends a virtual school and uses the internet. I have charter with 30 mb/s

Absolutely not. The bandwidth required to mine Bitcoin is very low as shown here: What are the bandwidth requirements of a mining rig?

  So that's 700 bits per second out and about 2,000 bits per second
  back. Essentially, zero.

This means that your son can mine 24/7 and your daughter won't notice any slowdowns whatsoever.


What does score tell me in getnetworkinfo? Using bitcoin-cli getnetworkinfo;

Or, going into Help>Debug>Console in bitcoin-qt and typing getnetworkinfo;

What does localaddresses:score tell me?

It's about the network reliability to other nodes, score keeps increasing the longer your node is reachable.


"Blockchain Explorer" software? I've been going to blockchain.info frequently to check addresses, transactions, blocks, etc. But since I've already got the blockchain on my hard drive, this seems kind of pointless. Is there any software similar to blockchain.info that runs natively on Linux, and uses Bitcoin-qt/bitcoind's blockchain, and therefore doesn't require an internet connection?

Abe does exactly what you want. I will walk the entire blockchain from bitcoin-qt/bitcoind and populate a local database. It supports several database backends including sqlite, Postgres, MySQL and Oracle.

It will take quite some time to walk the blockchain and populate the database, possibly a few days.

It has a web based interface that is very similar to blockchain.info and blockexplorer.


Sending coins when the priv/public keys are not in wallet (bitcoind) I've created the hex for a raw transaction but do not have the wallet priv/keys in the wallet. Can I still send the transaction using sendrawtransaction? I've checked the message using signrawtransaction and this returns complete.

Yes. You should not need the keys to be in the wallet to send a transaction using sendrawtransaction(). All sendrawtransaction() does is broadcast it over the network.


Who currently pays the miners for processing transactions? The graph: Bitcoin mining cost per transaction leaves an ambiguity. Who pays the transaction costs?

According to the list of available charts, that chart is showing "miners revenue divided by the number of transactions".  That is, it's the average amount a miner earns for each transaction they process.  "Bitcoin mining cost per transaction" isn't a very good title for the chart.

So far, the vast majority of miners' earnings comes from the 50 BTC per block rewards, with a tiny fraction coming from the transaction fees paid by the people creating transactions.

So to answer your question, nobody pays the vast majority of the cost; it is created out of thin air as the reward for mining a block.  You could see it that each new block generated inflates the money supply and so devalues all existing Bitcoins, in which case you could argue that everyone holding Bitcoin is paying via inflation.  But the inflation is predictable, and so already priced in.


why not make DIY, upgradeable, ASIC mining rigs? being a miner myself, I see one of the big problems in the mining field. ASIC's are very unsustainable at making profit, and quickly turn into scrap as something better comes along. (even though they can be super profitable at first)

What this does is centralize the wealth creation into the very first and wealthiest people who come and to buy, and drains the profits quickly for anyone else trying to get it. After the profits are drained, the equiptment becomes junk.

GPU mining is great because its a lot more doable for the average person (at a cost level) serves multiple uses and different coins, and allows a person to custom build their system, which they can update and upgrade as they move along.

So, why not just sell the parts for making ASIC rigs, and let mining enthusiasts build their own? I bet it would be a lot cheaper, and a lot more people could get their hands on ASIC chips.

it would expand the mining further to more people. more decentralization.

So why is this not being done? Do you think this could be a good idea? What do you project would happen?

So, why not just sell the parts for making ASIC rigs, and let mining enthusiasts build their own?

ASICs are highly specialized hardware, advancements in ASIC technology involve new hardware architecture (eg smaller, faster transistors), so a modular design would not allow a DIY-er to just add a new part on to keep up with the current tech. I think it would also be incredibly difficult to create a miner that is modular without losing efficiency when compared to a non-modular ASIC.

GPU cards are like a ‘general purpose’ miner, so if one coin is no longer profitable to mine, there may be another coin with a different algorithm that a miner can switch to. With ASIC chips, there is just one algorithm that the chip is optimized to run. For example, you could not use a bitcoin ASIC to mine ethereum, even if the ASIC was a modular design. You would need to swap out the chipboard itself to achieve this goal, and the chipboard is the most expensive part of the device.

From a manufacturer’s standpoint, if the majority of the unit cost comes from the chip itself, then the most straightforward business plan is to just sell the complete unit. Having a modular product means a lot of extra logistical considerations, which means increased prices for the end customer.


How can you construct a cycle with LND to rebalance one of your channels with another? I have at least two open channels, one of which has inbound capacity and the other has outbound capacity. How can I find a route and construct a payment to rebalance my channels against each other just using the LND commandline?

As in, what steps are necessary to stitch two routes together to form a cycle?

Create an invoice for yourself: lncli addinvoice <amt>
Pay the invoice specifying the outgoing channel and the last hop to take before paying you: lncli payinvoice --allow_self_payment --outgoing_chan_id <outgoing_chan> --last_hop <last_hop> <payreq_from_1>

To get the outgoing channel id use lncli listchannels --active_only. I usually have to grep for the remote_pubkey that I get from Zeus interface and then look for the chan_id string.
The last hop is the remote_pubkey of the node associated with the channel you want to increase the local balance on.
I learned this from this pull request documentation: https://github.com/lightningnetwork/lnd/pull/3736
Good luck rebalancing!


What options do I have to avoid API gap limit? I am using xpub keys I am building a app, and the design is, the "welcome page" has a qr code allowing the user to purchase a single-use of the app.

Blockchain.info conveniently allows you to use xpub to generate addresses, however, their docs mention bip 44, and the "gap limit"...  This is instantly a problem as I can imagine, say 30 users simultaneously going to the app (more realistically, 30 users going to the app under the amount of time it takes a single user to purchase), 20 will be presented bitcoin addresses to purchase, 10 will not due to the api throwing gap limit errors.

What options do I have to get around this?

I've had others suggest I just manually generate a bunch of private keys and not use xpub, but manually having to consolidate all of those single-transactions-per-address just sounds like an absolute nightmare that I would like to avoid.

UPATE

Is there any way at all to re-use the same address every time, but attach a guid to it so that when I see the txn broadcasted, I can link it with a given user's session?  This is really all that I need.  I don't need xpub.. I just need a way to identify that user A and user B both are viewing the welcome page, user A doesn't pay, user B does, user B is automatically given access, user A is not.

Issues related to gap limit as summarized in this blog post. Basically you have few options

Use wallets like electrum to increase gap limit setting
Automatically send small amount of funds to 20th unsued address to keep things going. This is done by services like blockonomics
Keep generating new address without worrying about gap limit. Later you can generate all private keys using xprv and sweep in the funds from all private keys.


Why does ONLY some connections have 'addrlocal' in getpeerinfo output I connected two laptops A and B to bitcoin testnet. I then manually connected B to A using addnode of bitcoin-client.

Snippet of getpeerinfo from B:

  {
    "id": 1,
    "addr": "172.22.94.40:18333",
    "addrlocal": "137.122.81.217:53818",

  }
 {
   "id": 10,
   "addr": "54.152.9.182:18333",
   "services": "000000000000000
 }

Some connection have an addrlocal set and its port 53818 is randomnly chosen. I searched through the codebase for this. It looks like some fInbound flag will be getting set in A. Can anyone in simple terms explain what is happening here?

I know that a socket cannot be used for listening and sending data at the same time. Is it got to do with that?

If 53818 is chosen as port to send data to A, then why is there no such random choice happening in seed node connection? (like 54.152.9.182 here in example)

I would guess addrlocal shows you your endpoint of the connection, that is your IP address and port number. For all incoming connections that would be the same as the IP address and port you are listening on, so that's why it's not displayed. In your case most likely: 137.122.81.217:8333

I'm not sure what would happen if the server is multihomed.


Electrum 2FA Wallet - Deriving the Third XPub I'm working on a project which requires me to take an Electrum mnemonic, determine its type and derive the corresponding addresses for that wallet.

I found lots of information on how to determine the mnemonic type and covert it into the master seed, but I'm struggling to understand how addresses for the 2FA wallet are derived. To be more exact, I was able to derive both extended keypairs (x1/ and x2/ in the wallet file), but I can't seem to be able to derive the third xpub (x3/ in the wallet file).

I've looked through the source code and it seems this key is derived by combining both xpub keys (the keys should be ORDERED) that can be derived from the master seed (x1/ and x2/), hashing them using SHA-256 and using that as the index when deriving the third xpub. A hard-coded xpub is used as the root.

I'm having trouble understanding / implementing this because the SHA-256 algorithm returns 32 bytes of data and the child index has to be 4 bytes long (as per the BIP32 specification).

Here's the code from Electrum that handles this.

def get_user_id(storage):
    def make_long_id(xpub_hot, xpub_cold):
        return bitcoin.sha256(''.join(sorted([xpub_hot, xpub_cold])))
    xpub1 = storage.get('x1/')['xpub']
    xpub2 = storage.get('x2/')['xpub']
    long_id = make_long_id(xpub1, xpub2)
    short_id = hashlib.sha256(long_id).hexdigest()
    return long_id, short_id

def make_xpub(xpub, s):
    version, _, _, _, c, cK = deserialize_xpub(xpub)
    cK2, c2 = bitcoin._CKD_pub(cK, c, s)
    return bitcoin.serialize_xpub(version, c2, cK2)

The functions are then called like this:

xpub1 = wizard.storage.get('x1/')['xpub']
xpub2 = wizard.storage.get('x2/')['xpub']
# Generate third key deterministically.
long_user_id, short_id = get_user_id(wizard.storage)
xpub3 = make_xpub(signing_xpub, long_user_id)

The long_user_id is 32 bytes long since it's the result of the SHA-256 function and it's then being used to call the make_xpub() function which is supposed to take in 4 bytes of data as the child index.

What am I missing here? Any input is appreciated.

After looking into the source code for the Electrum Wallet a bit further I was able to come up with a working implementation in JavaScript.

The problem I described in my question was that the long_user_id is 32 bytes while you only need 4 bytes to derive a child key. It turns out that the third xpub is actually not a child of the hard-coded signing xpub, but rather a root key derived from that signing key (i.e. it has a completely different chain code and its index is 0).

Here's the function I wrote which takes the two wallet xpubs (found under x1/ and x2/ in the wallet / keystore file) and the hard-coded xpub from Trustedcoin and derives the third xpub.

import HDKey from 'hdkey';
import crypto from 'crypto';
import secp256k1 from 'secp256k1';

function getCosignerXPub(xpub_x1, xpub_x2){
    const signing_xpub = "xpub661MyMwAqRbcGnMkaTx2594P9EDuiEqMq25PM2aeG6UmwzaohgA6uDmNsvSUV8ubqwA3Wpste1hg69XHgjUuCD5HLcEp2QPzyV1HMrPppsL";

    const xpubs = [xpub_x1, xpub_x2].sort().join("");
    const long_user_id = new Buffer(sha256(xpubs), 'hex');

    const hdkey = HDKey.fromExtendedKey(signing_xpub);

    const data = Buffer.concat([hdkey.publicKey, long_user_id]);

    const I = crypto.createHmac('sha512', hdkey.chainCode).update(data).digest();

    const IL = I.slice(0, 32);
    const IR = I.slice(32);

    const hd = new HDKey(hdkey.versions);

    hd.publicKey = secp256k1.publicKeyTweakAdd(hdkey.publicKey, IL, true);
    hd.chainCode = IR;

    return hd.publicExtendedKey;
}


Decentralized escrow functionality built into Bitcoin? AFAIK there are a few websites out there that offer escrow services for Bitcoin. Those however are central, i.e. I have to "trust" them.

Is it being discussed, is it theoretically possible, or does the blockchain technology already enable to implement a decentralized escrow service?

After all, it is easy to imagine that an escrow holder could be nothing more than a "virtual" party or a "bot", with its own wallet or private keys, that two negotiating parties could cast into existence. After the transaction has completed (or cancelled), the software would release (or revoke) the entrusted value to the respective party.

Update: If two parties cannot come to agreement, I can think of these solutions for now:

There could be a form of escrow option that will be chosen where at least one party is public facing and reputational, e.g. a (online) shop, that will be trusted by the other party not to deceive.
Two more "ordinarily" trading parties would choose an escrow option where the funds will never be released in the case of conflict at first. If they disclosed identity to each other, a court hearing could then be invoked which should usually come to a resolution, and the losing party will be enforced by law to provide value. Should Bitcoin never be accepted as negotiable matter by traditional jurisdiction, an alternative, equivalent infrastructure is thinkable, but let's leave that to another question for now.
This proposal by user Meni Rosenfeld:

  How about this. There is a box in which there are two types of coins,
  "deposit" and "payment". Both parties have permission to open the box.
  When the box is opened, the deposits go to whoever put them, and the
  payment goes to the party other than the one who opened it.

  So first the buyer and seller both put a small deposit in the box.
  This is safe since they can get it back. Then the buyer puts the
  entire sum of the payment in the box. Now:

  If the seller sends the goods, the buyer will open the box and the
  seller will receive the funds. He is incentivized not to be lazy or
  spiteful because he wants his deposit back.
  If the seller for any reason wants to back out of the deal, he can
  open the box and have the payment return to the buyer, and is
  incentivized to do so because he wants his deposit back.
  If the seller goes with the "reimbursement" plot, the buyer knows
  he is scamming (since the seller should have just opened the box) and
  ignore the request. (There is a potential weakness in that the buyer
  can "defect" and open the box anyway, to get the deposit. This may be
  alleviated by having the buyer's deposit smaller than the seller's,
  giving him more bargaining power).
  A fraudulent seller is not incentivized to try this on N people
  until it succeeds, since every failure costs him his deposit. Hence,
  scenario 3 in which the money is burned should very rarely happen.

  In any case this isn't supposed to be bullet-proof, just a significant
  extra protection for sellers who already pass the sniff-test.

  Additionally, the box can specify a charity address, agreed upon by
  both parties, to which the buyer has permission to send all funds,
  deposits and payment. So in the worst case the money will go to
  charity.

  I'm not sure about the technical implementation details but all this
  should be very doable.

I don't think it's possible in principle. The escrow service is one that is inherently authorized to make a decision as to who ultimately gets the funds. In a decentralized escrow service, who or what would make that decision?

If I place some coins in escrow as part of a transaction to you, something must decide whether those funds ultimately go to me or you. Obviously, that decision can't be made by me or you.

I have heard proposals where the coins are "burned" (lost forever) if both parties don't agree on who should ultimately get them. I think that's a pretty useless service as it allows one party to blackmail the other. "Release the coins to me and I'll give half of them back to you. Otherwise, they're lost forever."


What is the cost of setting up a bitcoin account does it 'cost' anything to set up an account? If bitcoins are virtual, why/how does an exchange rate work?

You are asking 2 very different questions so here goes:

1) Bitcoin wallets are free to create and use. blockchain.info, for instance, allow you to create an account and receive Bitcoin instantly. The only real cost is when you send coins out to someone - you have to pay the miner fee. The best you can do is read about it here https://en.bitcoin.it/wiki/Transaction_fees

2) Bitcoin are as virtual as Euros or US Dollars - it's a currency which you can trade like any other currencies. Few notable differences though - Bitcoin is finite, meaning there can only ever be 21 million Bitcoin ever produced. Miners are producing the coins by solving a complex algorithm. The more Bitcoins are mined, the more complex it becomes to mine and therefore more expensive in terms of resources (read electricity and hardware). Nobody can set a price to a Bitcoin, it's a market driven by demand and it is way more volatile than general currency trading. Exchangers just allow users to buy or sell Bitcoin for another currency but there is no guideline. That's why a lot of users are doing arbitrage between different exchangers in order to get the most profit out.

Hope that helps you


Jaxx Wallet ---> Cryptopea Wallet - unsuccessfull (doublespend) I attempted to transfer funds from my bitcoin jaxx wallet to my cryptopia exchange bitcoin wallet.

However transaction looks like it failed with doublespend error report.

Anything I can do?

This is the error.

and further down info.

I would suggest you to contact your wallet support team, let them know that you had this issue so that they can dig deeper maybe..

But as i can see transaction was confirmed so your coins was delivered to you, so you are fine.

See what is double spending, buy looks like your coins didn't succeed to double spend, so you are fine.

What is Double-spending?

Double-spending is the result of successfully spending some money more than once. Bitcoin protects against double spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent.

More information: https://en.bitcoin.it/wiki/Double-spending


How to add coinbase transaction with libblkmaker I currently trying to develop a simple Bitcoin miner in c++ for a project on my university. For parsing the 'getblocktemplate'-data I'm using libblkmaker.
Now I have to build the coinbase transaction for the 'blktmpl', but I don't really know how.

Anyone knows how to add a coinbase transaction to the block-template with 'libblkmaker'?

And how do I add my bitcoin address to this?

Thanks for your help,
Sebastian

To set a generating address, use set_generate_addr. blkmk_init_generation3 may also be what you're looking for.

The author of that library also wrote a miner, BFGMiner, that uses his library. Look at how he calls these libblkmaker function to add a coinbase transaction to the block header in miner.c.


How do light clients using compact block filters get relevant unconfirmed transactions? I was discussing various light client models and we got into unconfirmed transactions. With the BIP37-based bloom filters, a light client would subscribe to updates from full node peers by submitting its filter to the full nodes. A BIP37 filter could be applied to the mempool and a full node could notify the light client of unconfirmed transactions.
As far as I understands, compact block filters (CBF) are only created for confirmed blocks. This implies that a CBF-based light client would only hear about transactions after confirmation unless they had another mechanism to hear about unconfirmed transactions. Keeping up with the mempool would incur a lot of traffic. How would CBF-based light clients learn about relevant unconfirmed transactions without having all the downsides of BIP37-based wallets?

There's no design consideration in Neutrino / BIP157 for unconfirmed transactions, but it's not as much of a concession with context. A light wallet can effectively do nothing with information about an unconfirmed transaction as they can not verify anything about its validity to begin with. At best it is a suggestion that a transaction may have occurred, but this is even weaker than a normal unconfirmed transaction sent to a fully validating wallet.
It has always been an issue with "SPV" wallets that they can be duped into showing completely absurd false data, for BIP37 especially it was completely possible to sniff the incoming filter and dynamically produce transactions paying to the addresses that likely matched it billions of dollars. The client, as dumb as it is, can only show them to the user and hope that common sense on the part of the user prevails.


Who approves the feature and bug code reviews in Bitcoin? I see a list of Bitcoin feature and pull requests here. How do all million plus users agree to these feature/bug requests? Do all users of Bitcoin have to approve them, or who represents them in approving these code requests?
Where can I access the original, Satoshi written Bitcoin code?

How do all million plus users agree to these feature/bug requests?

Mostly by deciding whether to continue using Bitcoin-core or switch to one of the many other existing implementations of a Bitcoin wallet.
Those who are particularly competent to assess the changes are probably also, in many cases, competent to fork the code base and not introduce changes they object to. If others share their view of the changes, this might be viable. Certainly Bitcoin core has been forked many times in the past.

Do all users of Bitcoin [core] have to approve them

They mostly get to vote with their downloads.

Related questions

Where can I access the original, Satoshi written Bitcoin code?
Original default bitcoin script
Do "the official bitcoin developers" control Bitcoin?
Is the Bitcoin Core software managed by a central authority?

Other relevant sources of information

https://satoshi.nakamotoinstitute.org/code/


What happen if some blocks are added simultaneously with same previous hash In all of the blockchain samples that I see
e.g.
adilmoujahid,
Savjee
 as I checked, they added previous Hash by creating a block.

Suppose that, L is the current last block in a chain. Block A and B are created at the same time. So they set their previous hash with the same hash e.g. Hash of L.

What happens by mining when both of them are mined successfully, but B was mined faster.

Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.

What I want to reach, I think assigning previous hash by creating a block is not necessary, but by mining. Am I right?

A fork happens. If A and B are competing for the next block, they probably share transactions. So you cannot simply append A to B.

They're both valid blocks, nodes hold both of them until they hear about a new block that was built on top of either A or B. Let's say a node hears a new block C was built on top of B, that node will then disregard A because it isn't a part of the longest/heaviest chain. The transactions in A that are not in B are returned to the mempool to be mined in a new block.

The network reaches consensus by trusting the longest chain. This is why it is suggested to wait 6 confirmations for a transaction. This gives extremely high confidence that the network has reached consensus on your transaction and there is a very low probability that your transaction will be apart of a reorganization of the blockchain.


Can I double spend this transaction? b9d6d458f312b6ce2ef27bbb4a4a88f95e4a5db7aa04c9ab1f6225ecde47a77e

Can I move it ?

Thanks for your help

"Can I double spend this transaction?" as long as the transaction is unconfirmed you can try to make a new transaction with the same transaction-details but a noticeable higher fee. then you must hope that your new transaction (with the higher fee) will be executed before your b9d6d...-transaction will be executed. if this works the result would be that the b9d6d...-transaction will never be executed in future because there are not enough funds on your 1GDvWJUd7Hy...-adress. did you mean this by writing "double spend"?


how to calculate max spendable from all wallet Using latest bitoind, any way to calculate max spendable from wallet with some amount of outputs? For example i need to send all wallet amount to 2 outputs and set mining fee enough to get confirmation in first block. How can i calculate max spendable amount?

In Bitcoin Core, there is the option to subtract the fee from the amount. When you create a transaction, you set the amount to be the maximum amounts, and then you enable the subtract fee from amount options which will then reduce the specified outputs by the fee. This way, you can choose to send your entire balance without change and have the fee be subtracted from the output.

In the GUI (bitcoin-qt), there is a checkbox labeled "Subtract fee from amount" which you can set for each recipient. You can use the "Use available balance" button to auto-fill the full wallet balance. It will also automatically check that option for you.

If you are using bitcoind over the RPC interface, sendtoaddress has a parameter subtractfeefromamount which you can set to true in order to deduct the fee from the amount you are sending. sendmany has a similar option but it is instead an array of addresses so you specify the addresses that will receive less due to the fee being subtracted from their amounts.


Obtain the information about a bitcoin address I have a bitcoin address. How do I get it's balance and the amount of BTC (preferably in Satoshi) it's ever sent and received? I don't want to use any third-party bitcoin services, I want to do it as directly as possible. How can I do that?

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

To do that you have two options:

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

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

# look up historical transactions
txindex=1

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


Bitcoin mining algorithm - target - Java Default share difficulty is 1 (big-endian target for difficulty 1 is 0x00000000ffff0000000000000000000000000000000000000000000000000000)

How to calculate this?
How it look like on Java code?
What algorithm of calculate this value?

The difficulty is a part of the block header called "bits". It is the 72nd to 75th bytes of the block header and looks like this in hex:

bits = 0x76270618

Remember this is little-endian! Actual big-endian version is 0x18062776
Take the first byte as the “exponent” and the other three bytes as the “coefficient”

Exponent = 0x18 = 24

Coefficient = 0x062776

Plug into this formula:

Coefficient * 2**(8*(Exponent - 3)) =
0x0000000000000000062776000000000000000000000000000000000000000000

And that's how you can calculate difficulty from bits.


How will Ripple handle the 50,000+ advertised TPS? I've tried wrapping my head around the Ripple "consensus process". From my understanding, Ripple creates a new ledger version every 4 seconds, computed by a set of "validating nodes".
But herein lies my question, how will the validating nodes push a new ledger version at the scale of their advertised capacity[1]? How would validating nodes with slower connections keep up?
[1]: https://ripple.com/xrp/

There's a self-regulating mechanism that keeps the network running so that it's not as fast as the fastest validator (as that would make attacks too easy) nor as slow as the slowest validator (as that would provide poor performance). But Ripple has never claimed on ledger transactions rates that high. To get to 50,000 TPS, you need to use off-chain scaling schemes like payment channels.

This is a fundamental scaling limit with all public ledgers that try to create fungible tokens. Every full node must process every transaction and thus if you try to get the number of on chain transactions very high, you impose high bandwidth, CPU, and storage costs on everyone. (You can trade off some fungibility, as IOTA does and as some sharding schemes do.)


Specify which CPU threads are used using cpuminer I'm using the latest version of cpuminer on a quad core cpu. How can I tell it which physical cores to use, 2 threads uses 1 and 2 but I want it to use 3 and 4 instead as I have other things using core 1 and 2 which are not optimised for more than 1 cpu core.

Don't worry about it, just let your OS take care of the scheduling. As long as you're not trying to run more CPU-bound threads than you have cores, you'll be running as efficiently as you can. Even a single threaded program will bounce around between cores (you can see this by looking at a CPU usage graph, and your single threaded program will probably use 25% of each of a quad core system on average).


attack bitcoin through writing data directly into output's scriptPubKeys In this post, Steve Ellis wrote :

  "[...]Writing data directly into a output's scriptPubKey is not prunable[...]where as non-prunable outputs will forever create bloat and slowdown the set traversal(e.g. during block verification).[...]

Wouldn't this be a relatively cost effective way to slow down bitcoin by writing the maximum possible data into into scriptPubKey?

No. This is very fast way to spend your money for nothing. You can not put arbitrary data into to scriptPubKey because there is limited number of standard scripts.

The best thing you can do nowadays is sending 550 satoshi (0.00000550 btc) for bare-multisig outputs m-of-3 created from uncompressed public keys. This will enlarge the UTxO database ( look at https://statoshi.info/dashboard/db/unspent-transaction-output-set ) but will not slow down network itself


Why is my "spendable_msat" much lower than "msatoshi_to_us"? Today I was attempting to send a Lightning Network payment via c-lightning, version v0.7.1-64-gbb30104, using a channel I established in 2018. Strangely, my payment kept failing even if the destination was routable. Finally, I noticed the reason was a relatively large disparity between  spendable_msat and msatoshi_to_us.

"msatoshi_to_us" : 49947931,
"to_us_msat" : "49947930msat",
"msatoshi_to_us_min" : 49947930,
"min_to_us_msat" : "49947930msat",
"msatoshi_to_us_max" : 50000000,
"max_to_us_msat" : "50000000msat",
"msatoshi_total" : 50000000,
"total_msat" : "50000000msat",
"dust_limit_satoshis" : 546,
"dust_limit_msat" : "546000msat",
"max_htlc_value_in_flight_msat" : 18446744073709551615,
"max_total_htlc_in_msat" : "18446744073709551615msat",
"their_channel_reserve_satoshis" : 546,
"their_reserve_msat" : "546000msat",
"our_channel_reserve_satoshis" : 546,
"our_reserve_msat" : "546000msat",
"spendable_msatoshi" : 35617930,
"spendable_msat" : "35617930msat",
"htlc_minimum_msat" : 0,
"minimum_htlc_in_msat" : "0msat",
"their_to_self_delay" : 144,
"our_to_self_delay" : 144,
"max_accepted_htlcs" : 483,
"status" : [
  "CHANNELD_NORMAL:Reconnected, and reestablished.",
  "CHANNELD_NORMAL:Funding transaction locked. Channel announced."
],

As you see, my "spendable_msatoshi" is much lower than "msatoshi_to_us", a difference of 14373070 msatoshis. Even considering "their_reserve_msat" and "our_reserve_msat", it can only explain an amount of 1092000 msatoshis, or ~7% of the unspendable fund, where does the rest go?

Why does this even occur? And what should I do to fix it?

I tried reading the source code of c-lightning, and clearly HTLC and transaction fee is also deduced from "spendable_msat", however, those values are invisible in lightning-cli listpeers and I still cannot determine the reason.

/* Compute how much we can send via this channel. */
if (!amount_msat_sub_sat(&spendable,
             channel->our_msat,
             channel->channel_info.their_config.channel_reserve))
    spendable = AMOUNT_MSAT(0);

/* Take away any currently-offered HTLCs. */
subtract_offered_htlcs(channel, &spendable);

/* If we're funder, subtract txfees we'll need to spend this */
if (channel->funder == LOCAL) {
    if (!amount_msat_sub_sat(&spendable, spendable,
                 commit_txfee(channel, spendable)))
        spendable = AMOUNT_MSAT(0);
}

/* We can't offer an HTLC less than the other side will accept. */
if (amount_msat_less(spendable,
             channel->channel_info.their_config.htlc_minimum))
    spendable = AMOUNT_MSAT(0);

/* We can't offer an HTLC over the max payment threshold either. */
if (amount_msat_greater(spendable, get_chainparams(ld)->max_payment))
    spendable = get_chainparams(ld)->max_payment;

json_add_amount_msat_compat(response, spendable,
                "spendable_msatoshi", "spendable_msat");
json_add_amount_msat_compat(response,
                channel->our_config.htlc_minimum,
                "htlc_minimum_msat",
                "minimum_htlc_in_msat");

You basically answered the question already yourself. Besides the 1% channel reserve you as the funder are responsible for paying onchain fees in case you need to force close the channel by spending the commitment transaction.

C Lightning (and lightning nodes in general) are rather overestimating onchain fees as they cannot rely on the fact that the fees that where taken when the commitment transaction was signed will work in the future if force closing of the channel takes place.

Look for example at this transaction in which my c Lightning node had a channel to test the lightning app (running lnd) and a cross implementation bug produced a forced channel close. You can see that I paid about 100 satoshis per byte in fees resulting in 18312 satoshis. This is the same ballpark number as the value which you describe here. (looking at the mempool this number sounds realistically to me)

Things you can do

Don't force close channels (fees will be much smaller with mutual closes, since the fee is more accurate and only one tx is needed)
Have bigger channels then the relative fee is not so high
Look at the code where fees are set. Propose better strategies in the c Lightning issue tracker or provide an api to set / read them. (as far as I remember there is currently no api for that)
You cannot even do too much as the fees being used are negotiated between you and your channel partner. If the channel partner starts out with a really high fee there is hardly anything you can do to defend against this.

Btw welcome to the rabbit hole of onchain fees with lightning. Doing this for a while now I realized it is one of the most subtle and present challenges that we are facing.


Security for Lightning Network nodes? Imagine a Lightning Network node A that maintains a bidirectional payment channel with one peer B. For this channel to be maximally useful, some of its value must belong to A. To update channel state, A must have ready access to one or more private keys. To communicate with B, A must also maintain a network connection.

Putting these three requirements together means that A must maintain a hot wallet controlling value. Ordinarily, this would open A up to loss of funds through network-based attacks.

The case of a Lightning node is more nuanced in terms of what can be stolen and what can be done with stolen material.

Three pieces of cryptographic material can potentially be stolen:

the private key allowing the node to update channel state;
the preimage of the current state's hash value, or previous preimages;
one or more channel states.

Now imagine that an attacker breaks into A:

he can not steal the money for himself without B's private key;
he can try to sell the preimage of the current state's hash value to B;
he can publish the current hash value preimiage, allowing B to steal the money;
he can sign an publish the current channel state (closing it without contention), or a previous state (allowing B to steal the money).

So an attacker is much more restricted than otherwise. He can't steal money outright. But he can work with B to steal the money. Alternatively, if B is the attacker, then no collaboration is needed to claim the entire channel value.

Is there anything I'm missing here? What countermeasures could A deploy to further limit what can be done in the event that an attacker gains access to one or more pieces of cryptographic material?

So I think you're missing some things. Since the Lightning node has bitcoins in the channel and can be used as a conduit for B to send or receive money, node A must have an automated way to sign bitcoin transactions and participate in lightning transactions. An attacker could theoretically use this ability to send bitcoins from the channel through the lightning network to themselves, in the case that the attacker compromises the machine in such a way as to have the ability to instruct the Lightning node to do those things. The private keys would still be in memory at very least, and so could potentially be accessible to kernel viruses.


Lightning network in real world Newbie in this area. Trying to understand how lightning network would work in real world.
If I want to buy a coffee on BTC network, I go and pay and unfortunately me and the cashier need to wait 5-10 min before the transaction is "confirmed" on chain. This the cashier wouldn't know for sure if my money is good for that amount of time.
With lightning network, my understanding is that we would be making a transaction on a "side chain" (so the money would be transferred "instantly").
My question is that instantly - Does the lightning network also solve the problem of giving confidence to the cashier that I have the money required? I.e. does the cashier have to wait for the side chain to get "settled" onto the main chain and thus wait 5-10 minutes for a confirmation?

With lightning network, my understanding is that we would be making a transaction on a "side chain"

The lightning network is not a ‘side chain’, that term is usually used to describe an entirely different piece of technology that can be built to work on top of/alongside bitcoin.

Does the lightning network also solve the problem of giving confidence to the cashier that I have the money required?

Yes, lightning payments can settle pretty much instantly, both the customer and cashier would see proof of this in their respective lightning wallet applications. There is no need to wait for an on-chain transaction to be confirmed.


Lightning Network: hashlocks vs private keys exchange I am reading the Lightning Network paper and noticed that when describing bidirectional payment channels, the authors used "Breach Remedy transactions" and the exchange of the two parties' private keys to discourage any of the parties to broadcast an old commitment transaction. This is indeed an effective solution, however I read in more than one place (e.g. here, here) that this is actually achieved through hashlocks (i.e. the two parties create hashlocked transactions from their commitment transactions and share the hashlock secret instead of exchanging their private keys to discourage the broadcasting of previous commitment transactions when they update the channel). In the paper, hashlocks are used when the bidirectional payment channels are used to relay payments among more than two nodes, however they are not used for payment channels between two nodes.

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange?

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange?

Either way will work, but hashlocks are simpler. They're described in section 4 of the paper you linked. In a private key exchange-based system, you need to store every breach remedy transaction, (about 250 bytes) but in a hashlock system, you only need 20 bytes for each preimage.

You don't need to store every preimage, either. Murch explains and links a system to store every hash in a channel with 64*20 bytes of memory at most here: What is a hash pre-image as it is used for the breach remedy?


Is there a Bitcoin casino that is willing to collaborate on some economics research? Am looking to collaborate with the owners of some of the online Bitcoin casinos. I am in the process of designing some behavioural experiments to test for biases in Bitcoin gamblers.

I will sign NDA agreements with whoever wants to talk to me about them and am also happy to go through a fiduciary to anonymise which site the data comes from.

Thanks

Jonathan

A lot of gambling games are completely on-chain, you can analyze the blockchain and look for these transactions to get the data you're looking for.


Is the block 'chain' actually a merkle tree? Forgive the noob question, but I have just started seriously looking into block chain and bitcoin.

I tried to implement a very, very basic version of what I understood the block chain to be to understand it better, and eventually found out that bitcoin does not store account balances. It instead references previous transactions for inputs and outputs.

This then led me to reading about the Merkle tree, and how all transactions are derived from the root of the Merkle tree. Does this mean that block chain technology does not actually represent a chain, but rather a tree structure where a certain number of transactions in a specific sub-tree constitute a block of transactions? Or have I just misunderstood it? The very fact that its called blockchain technology is throwing me off.

Each block contains a merkle tree of new transactions and the hash of the previous block. New transactions can consume the outputs of previous transactions and create new unspent outputs for future transactions.

Bitcoin currently does not maintain any kind of universal or canonical tree of all unspent outputs. Individual nodes are free to maintain a database of UTXOs (unspent transaction outputs) using any method they prefer.

The blocks do literally form a chain since each block contains the hash of the previous block.

Ripple works in a somewhat simpler way. There are accounts with balances that are arranged in a Merkle tree. Each ledger contains the hash of the previous ledger, a Merkle tree of transactions and the deltas to the state each transaction created, and the hash of the new Merkle tree of system state.


In BitcoinJ, do I need to run downloadBlockChain() again after adding a new key? I added a Wallet instance to PeerGroup instance and executed downloadBlockChain() method. Now if I add a key(s) to that wallet, do I have to execute downloadBlockChain() again to get a current balance including a new key or will it show a right balance automatically, assuming the new key has some balance?

Yes. You must call clearTransactions(0) on the Wallet, followed by downloadBlockChain() on the PeerGroup.

BitcoinJ is a thin client, meaning it doesn't download transactions for addresses that aren't in its wallet.

https://bitcoinj.github.io/working-with-the-wallet#replaying-the-chain


Why I'm getting different merkleroot? I'm using merkle.cpp code (which uses the libbitcoin library for some helper functions) from Mastering Bitcoin book.

I was trying to re-create Merkleroot hash for Bitcoin block #100000 containing 4 transactions:

 "tx": [
    "8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87",
    "fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4",
    "6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4",
    "e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d"
  ].

Thus, I modified main() function by adding hashes of all four txs:

int main()
{
    // Replace these hashes with ones from a block to reproduce the same merkle root.
    bc::hash_list tx_hashes{{
        bc::hash_literal("8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87"),
        bc::hash_literal("fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4"),
        bc::hash_literal("6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4"),
        bc::hash_literal("e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d"),

    }};
    const bc::hash_digest merkle_root = create_merkle(tx_hashes);
    std::cout << "Result: " << bc::encode_base16(merkle_root) << std::endl;
    return 0;
}

Compiling and running it gave me:

Current merkle hash list:
  15b88c5107195bf09eb9da89b83d95b3d070079a3c5c5d3d17d0dcd873fbdacc
  49aef42d78e3e9999c9e6ec9e1dddd6cb880bf3b076a03be1318ca789089308e

Current merkle hash list:
  6657a9252aacd5c0b2940996ecff952228c3067cc38d4885efb5a4ac4247e9f3

Result: 6657a9252aacd5c0b2940996ecff952228c3067cc38d4885efb5a4ac4247e9f3

while the actual merkleroot is different:

"merkleroot": "f3e94742aca4b5ef85488dc37c06c3282295ffec960994b2c0d5ac2a25a95766",

What I did wrong?

You actually did get the same hash. It's just that every Bitcoin software displays hashes byte swapped. If you look closely, you'll see that the first byte of your result (66) matches the last byte of the displayed merkleroot. The second byte matches the second to last byte, and so on.

Internally, the merkleroot (and other hashes) are in the same order as the output of the hash function. But for display to users, they are always byte swapped.


Is it possible to add two secp256k1 points to get a "shared key"? As I know from the Elliptic Curve Diffie Hellman (ECDH), you can create a "Shared Key": https://asecuritysite.com/encryption/ecdh2

This will look like this:

dA × dB × G = Shared Key

QB = dB × G

QA = dA × G

But is it possible to get the sum of dA and dB? (Plusing the value of each private key?)

dA + dB × G = ???

How to get a "Shared Key" when adding each private key (plus)?

Yes, QA + QB = (dA + dB) × G, but this isn't used in ECDH as QA + QB can be calculated by third parties.

You can read about this property here.


Bitcoin HD wallet forwarder without depending on a 3rd party? I want to setup a REST API service that does 3 simple things.

Ask it to generate a new address (ideally from a BIP32 xpub key tree)
Notify my server application when a deposit and confirmation X happens.
Once the deposit is confirmed, forward the funds to another address and invoke a script in PHP or node.

I was originally going down the bitcoind walletnotify route but a few issues popped up (namely no HD support, scalability of having 10000's of addresses being monitored on a bitcoind is apparently a bad idea??  Is this true?).

I've therefore been setting up Ubuntu as a server and looking at bitcore + bitcoind with node.js to solve this which is painful on v14.04 for some reason... am I barking up the wrong tree and/or is there an easier approach?  I can't believe I'm the only one who's needing this so feel like I'm missing an obvious trick here as it's like pulling teeth.

I don't want to rely on a 3rd party server because if they disappeared I don't want to risk my business collapsing overnight.  I am happy using 3rd party code base or servers if they are open source though.  I've used blockchain.info's API previously which was excellent but really want an in house solution.

I don't know of a solution that works out-of-the-box with the requirements you've set. However, you can do some of what you need using some command-line tools available on github.

Pycoin has a key utility which can be used to derive bip0032 addresses given a root. Here's a quick primer on how to use it:

$ git clone http://github.com/richardkiss/pycoin
$ cd pycoin
$ sudo make
$ ku <your xpub or xprv key> -s 0/1/2/3/4

This will show you the data on the bip0032 key at the path m/0/1/2/3/4. If you add the -a argument, you can get the address at this path. If you add the -W argument instead (using an xprv key), you get the WIF format. This WIF format can be imported to bitcoind and that in turn can be used to notify you and do what you need afterwards. You can delete that key after payment, which should generally leave the number of addresses being watched lower than it might be (though you'll want to purge every once in a while). This could work, but I would NOT recommend it as it's horrible security. Of course, that's probably why you're forwarding funds to another address right away, so that makes sense.

You're going to have to write some code regardless. bitcore is a fine library for doing HD wallet stuff, but the notification is always the tricky bit.


How many addresses are sent in response to a getaddr message? I've been trying to determine the number of addresses a node sends when it receives a getaddr message but I'm a little confused.

On one hand, on addrman.h/.cpp I can see that:

// the maximum percentage of nodes to return in a getaddr call
#define ADDRMAN_GETADDR_MAX_PCT 23

// the maximum number of nodes to return in a getaddr call
#define ADDRMAN_GETADDR_MAX 2500

[...]

int nNodes = ADDRMAN_GETADDR_MAX_PCT*vRandom.size()/100;
if (nNodes > ADDRMAN_GETADDR_MAX)
    nNodes = ADDRMAN_GETADDR_MAX;

So it seems that the number of addresses sent is the smaller of the two conditions, namely, 23% of the (active known) nodes or 2500 nodes.

But on the other hand, from the bitcoin wiki:

  The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers.

...and...

  [About addr messages] If the sender sent over 1000 addresses, they are all ignored.

So, why does a node try to send 2500 addresses if the receiver is going to discard them? Why not sending at most 1000 addresses?

The result from CAddrMan::GetAddr() is fed to CNode::PushAddress, which filters out addresses the peer already has, and inserts them in a temporary buffer of up to 1000 addresses.

Later, in SendMessages(), the contents of that buffer is sent out periodically.


Where can I get bitcoin customer support? Is there a support number? I have a bitcoin problem. My transaction is unconfirmed, etc

Is there a support number that bitcoin users can call for help?

Bitcoin is not a business, it is a decentralized computer network, where no one person or organization is in charge. Thus there is no customer support number for bitcoin, like you may be used to with your bank, credit card, etc.

Note that even though bitcoin itself is not run by a business, there are businesses that operate within the bitcoin ecosystem. For customer support regarding those businesses, you'll need to contact them directly.

But for general bitcoin questions, you're in the right place to ask for support regarding your problems. Just like bitcoin is a decentralized cryptocurrency where no particular person is in charge, its 'support team' is also decentralized and scattered across the world. I put 'support team' in quotations because the participants of this Stack Exchange site are not employees of bitcoin or Stack Exchange, instead, they are here of their own accord, volunteering their time and knowledge to help others. There are many users here with a great knowledge regarding cryptocurrencies, so if you ask a good question, you will likely receive a great reply.

You could elaborate on your problem a bit for a better response.

Where did you do the transaction?
Did you pay the miner fees?
Did your wallet software give any response?
Were you trading/transacting on an exchange?
The transaction id (TXID)
Did your transaction make it to the memory pool (mempool)?

I see that you're new to StackExchange.

Please edit your question for some significant help.


OP_RETURN marks transaction or output as invalid I am currently looking into the Bitcoin script. I want to create a transaction with one output with OP_RETURN and some data, and one output which pays coins to some address. I am confused, does OP_RETURN mark the whole transaction as invalid or just the output.

I am especially confused because the wiki is not clear on this issue:
https://en.bitcoin.it/wiki/Script#Flow_control
(says the whole transaction is marked as invalid)
https://en.bitcoin.it/wiki/OP_RETURN
(says just the output is marked as invalid)

Both.

Transaction output scripts are only executed at the time they are attempted to be spent.

If you try to spend an OP_RETURN output, the spending transaction is invalid, as this instruction immediately fails the execution.

As a result, OP_RETURN outputs (not the transactions they are in) are unspendable.


Bitcoin Wallet Crash Report I was into bitcoin back when it started years ago, but over the years I got busy with other things and forgot about it until all the recent news. I was able to locate two emails from 2011 notifying me of Bitcoin wallet crash report. I think that was about the time I also switched phones from android to apple.
The below info is what's in the email sent to me. Will I be able to retrieve my wallet info from the information in this email? If so, please explain how I can access this wallet again. Information listed as (XXXXX) is identifying information I have left out of the email chain log. Thank you in advance for your assistance.
Date: Thu Nov 10 10:13:26 CST 2011
Version: 1.39 (55)
Package: de.schildbach.wallet
Phone Model: LG-P509
Android Version: 2.2.2
Board: thunderg
Brand: LGE
Device: thunderg
Display: FRG83G
Finger Print: LGE/thunderg/thunderg/(XXXXX):user/release-keys
Host: android-buildserver
ID: FRG83G
Model: LG-P509
Product: thunderg
Tags: release-keys
Time: (XXXXX)
Type: user
User: (XXXXX)
Configuration: { scale=1.0 imsi=310/260 loc=en_US touch=3 keys=1/1/2 nav=1/1 orien=1 layout=18 uiMode=17 seq=25}
ScreenLayout: size 2 long 16
DisplayMetrics: DisplayMetrics{density=1.0, width=320, height=480, scaledDensity=1.0, xdpi=159.37254, ydpi=160.42105}
Databases: address_book webview.db webviewCache.db

=== collected at exception time ===

Total Internal memory: 209190912
Available Internal memory: 27512832

java.lang.NullPointerException
at android.widget.TextView.onTouchEvent(TextView.java:6831)
(XXXXX)

Contents of FilesDir /data/data/de.schildbach.wallet/files:
2011-11-10 10:13:26  files  [0]

2011-11-09 10:56:28  wallet (XXXXX)
2011-11-10 10:13:26  key-backup-(XXXXX)
2011-11-09 12:47:42  key-backup-(XXXXX)
2011-11-10 10:13:26  key-backup-(XXXXX)
2011-11-10 10:13:26  key-backup-(XXXXX)

Contents of CacheDir /data/data/de.schildbach.wallet/cache:
(XXXXX)

Before doing anything I would make some extra copies of those files onto some other media.
I think you should probably be able to download the latest version of the "Bitcoin Wallet" for Android (less ambiguously known as the Schildbach wallet) onto a new Android device, copy the backup file to the device, and then use the wallet's features to recover from those backup files. Menu, Safety, Restore, specify file. You might need to know the password you chose.
If a password was set, the files will be encrypted. There are programs that can help to find a password if you have some ideas about the password. One is btcrecover:

Bitcoin wallet password recovery support for
[...]

Bitcoin Wallet for Android/BlackBerry spending PINs and encrypted backups


If a court orders mining pools to seize funds, they will modify their software to do it, or be shut down' - can this happen? I thought nodes could prevent this too.  but if enough miners did do this, what could happen in worst case?  thanks in advance for responding

To spend some BTC, the network’s nodes will require a valid cryptographic signature on the transaction that consumes the UTXO in question. Each UTXO is locked to some bitcoin address, and to create a signature that is valid for that address you’ll need knowledge of the private key used to derive/create that address.

So a miner is not in any sort of privileged position to spend coins that are not theirs, since they do not have knowledge of everyone else's private keys. No matter what a court mandates, the miner will be unable to legitimately spend coins they don't own. Any attempt to do so would be easily identified as cryptographically invalid.

A miner could start creating blocks which move arbitrary coins to addresses of the miner's choice, but these transactions and blocks would be rejected by the rest of the network of nodes, so it would be of no consequence to the network. The miner creating these fraudulent transactions would simply be ignored.

Each network node is an individual instance of the code, working to independently verify the state of the network. Even if every miner started to break the rules, the nodes would simply ignore them (and we’d expect some miner to eventually capitulate and start mining valid blocks again, since they will gain profit for doing so, and otherwise lose money by mining invalid and useless blocks).


Is an AntMiner S7 batch 14 good? I was looking at my new Butterfly Jalapeños while logging on to my Bitcoin Wallet (My new one as I still haven't found the old one.) and realized how inefficient the Butterfly Jalapeños were. So I started looking up Bitcoin miners. I came across the AntMiner S7 and thought it looked amazing, I also calculated that it would make over $4 USD every day for a total of over $100 every month. I did some more research and could find no problems with it. I was wondering if anyone knew of ANY problems of any kind with the AntMiner S7's. Thanks for the help.

-GoldNugget8

The most obvious problem, it appears to me, is that they cost $1200. If you make $4 per day (assuming that's net profit after paying for electricity), it'll take about a year to pay for itself. That's assuming the mining difficulty stays the same for a year, which it almost certainly will not; in the last 12 months (March 2015 to March 2016), difficulty has more than tripled.

Unless the value of Bitcoin rises substantially (faster than difficulty), I'd be skeptical of coming out ahead.


Bitcoind installation on ubuntu How would I go about installing bitcoind to a specific directory in ubuntu?
https://gist.github.com/rjmacarthy/b56497a81a6497bfabb1
I'm following that instruction but it downloads to .bitcoin by default and I want to change to somewhere else

Welcome to Bitcoin.SE!

You need to add the -datadir={dir} parameter to your command line.

A full list of command line options is available if you key bitcoind --help


Why must the entire chain be included in calculations if it's already been validated. Why can't the validated portions be archived to save energy? I'm new to this so don't laugh.  If all of the previous transactions in a blockchain have been validated as authentic, why does the entire chain have to be carried forward in the calculations?  Why can't the validated portions be hashed and archived to save energy costs from handling so much historical data.  When accountants calculate the current years income, they don't go back to when the company started and add up every income and expense item, they just add the current years results to the archived past totals.  What am I missing.

There is no difference between those two things. If you have a data set that includes only things that you have fully validated all of and you confirm that something is in that data set, you have fully validated all of it. So checking that it's in a data set of things you have validated cannot be done instead of validating the entire chain because it does validate the entire chain.
I'm not sure what you mean by "archived to save energy". If they aren't archived, they're stored. If they are archived, they're stored. So I'm not sure how energy would be saved.


BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications The message "BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications" is appearing regularly in my debug.log. When these messages appear, I can be sure that lnd will not be able to complete syncing to the chain and thus unable to fully start.

This message occurs after the "txindex thread exit" message, and can be triggered with a "bitcoin-cli getrawtransaction xxx" call. I don't know how to resolve this, or even to determine what state the txindex is in. Restarting bitcoind does not help.

I am running Bitcoin Core version v0.18.0 (release build).

One way to solve this seems to be to disable and then reenable txindex. In other words, stop bitcoind, set txindex=0 in bitcoin.conf, start bitcoind, wait until fully started, stop bitcoind, set txindex=1, start bitcoind, wait until message "txindex is enabled at height xxx".

Unsure why this is necessary though.


How are txns sorted correctly in Merkle trees between nodes and validated via Proof of Work I am interested in exactly what happens to transactions in the pending block (block that is being mined at the time). From what I understand, transactions are the stored as a Merkle tree hash inside the block, along with the parent hash, timestamp and nonce. During mining, the miner is hashing the block data with a different nonces' trying to achieve the target hash. I assume what they are hashing is all the block data including the merkle root. But the merkle root must be different to each miner/node due to transaction order and the generation transaction, so how do other nodes come to consensus if their transactions are different. There is a hole in my understanding.
Furthermore, when transactions are broadcasted across the network, nodes will receive them at different times due to network latency etc. and miners can rearrange the order of transactions due to fee incentives, but this changes the merkle root. I understand that miners prove they have done the work to validate the transactions, but what steps do other nodes take to go 'looks legit'. I imagine they would use the nonce provided by the block creator to hash their own copy of the block and see if it in within the target.
Also, If PoW is done on the block data with the merkle root, how can new transactions be added to the block? Wouldnt the tree have to be hashed again and the PoW would have to start from the beginning. Does a miner wait for the block size limit to be reached before performing PoW? I don't understand how PoW can be done on a dynamic flow of transactions, and how every node can have the exact same set of everything to do PoW on.
Can someone please explain what I am missing? How are transactions sorted by different nodes? How do transactions enter the merkle tree? How do other nodes validate the new block?
Thank you heaps.

But the merkle root must be different to each miner/node due to transaction order and the generation transaction,

Correct.

so how do other nodes come to consensus if their transactions are different.

They don't. Every miner is fully responsible for the choice of their own transactions. There is no need for different miners to agree on the transaction selection. The winning miner decides the contents of the winning block, and other go along with it, accepting their transaction selection (unless the included transactions are objectively invalid, which makes the block invalid - to miners and other nodes).

I imagine they would use the nonce provided by the block creator to hash their own copy of the block and see if it in within the target.

There are many block validity rules that are performed by all nodes, including the verification of proof-of-work, like you say. Other rules include verifying that all transactions are valid, that no theft occurred, that no double spending occurred, that no money is printed by the block (beyond the permitted subsidy), ...

Wouldnt the tree have to be hashed again

Yes.
There are a number of layers involved to updating a miner's candidate block. Each is much faster than the previous one, but done much more often:

Typically the mining software will occasionally (say, every few seconds) build a new block template to work on, which includes transaction selection.

An intermediate layer changes the coinbase transaction (which includes payout address, as well as an "extra nonce") every so often. Every time this happens the Merkle root changed. However, by caching the inner nodes of the Merkle tree that are just right of the leftmost branch in the tree, this is just O(log(n)) work in the number of transactions (e.g. a block with 2048 transactions only needs 11 hashing steps to recompute the Merkle root).

The lowest-level hardware layer cycles through the 232 nonces in the block header, all with the same Merkle root. This is extremely efficient.

and the PoW would have to start from the beginning.

Yes, but this is irrelevant. PoW doesn't have "progress". You don't lose anything by starting over, as long as you're still trying hashes all the time. Every candidate block you try (combination of tx selection, coinbase tx, nonce) has an independent chance of meeting the PoW target (a chance equal to 2256 / target). If that chance is 1/c, and you perform h hashes per day, you will find h/c block per day - regardless of which transactions those attempts are for.


Do transactions happen in an already mined block or a block yet to be mined? As I understand it a miner gets a reward of 25 BTC per block he finds (as of now). I also read that some transaction fees go to the miner who found the block.

How are these two things related?

Also, how can a miner not claim all the fees? Ain't that automatic? Is there something the miner needs to do after he found the block to claim the fee?

How was the system "boostrapped" with the first block ever?

A new block is constructed using transactions from the queue of pending transactions.  The miner repeatedly hashes the data until the result meets the network difficulty level.  The local bitcoin node then broadcasts the block to the network.  The process then repeats with the next set of pending transactions.

The miner gets the block fee as well as all transaction fees for the transactions included in the block.  Note that the miner receives nothing if the block is orphaned because another miner broadcast his block first.  In the case of a pool, the fees are divided among all of the miners in the pool.

Each block contains a coinbase address and this is the address that receives the fees.  The miner can set this address to anything he wants.

Satoshi started the process by releasing the genesis block, which is the initial block in the block chain.


listtransactions weird offset workflow I need to extract last wallet transaction. But seems  listtransaction has some wrong logic. When I perform this function
listtransactions '*' 50 9

it just return me first records not last. In my case I have 11 records, so it return me record 1 and 2, instead of 10 and 11 as I expected. Thus I get first two records instead of last. Maybe I understood something wrong or missed some other params?

I need to extract last wallet transaction.

This will return last transaction in the wallet:
listtransactions "*" 1 0

For second last transaction:
listtransactions "*" 1 1

Last two transactions:
listtransactions "*" 2 0

Consider a wallet has 5 transactions.
listtransactions [LABEL] [COUNT] [SKIP]

Skip
Tx

0
Tx5 [END]

1
Tx4

2
Tx3

3
Tx2

4
Tx1 [START]

If you skip 0 and count 1 in the above table you will get Tx5
If you skip 0 and count 2 in the above table you will get Tx4 and Tx5
If you skip 1(Tx5) and count 1 in the above table you will get Tx4
If you skip 1(Tx5) and count 2 in the above table you will get Tx3 and Tx4


Does the alternative stack make Script Turing complete? The wiki documents the presence of an "alt stack" in Script:

OP_TOALTSTACK Puts the input onto the top of the alt stack. Removes it from the main stack.
OP_FROMALTSTACK Puts the input onto the top of the main stack. Removes it from the alt stack.

It appears then that Script may qualify as a Two-Stack Pushdown Automaton. And this system is known to be equivalent to a Turing Machine. For example:

  To see the equivalence, just think of the first stack as the contents of the tape to the left of the current position, and the second as the contents to the right. Start by pushing the normal "bottom of stack" markers on both stacks, then we can simulate the TM by popping from the right stack and pushing to the left to move right, and vice versa to move left. If we hit the bottom of the left stack we behave accordingly (halt and reject, or stay where you, depending on the model), if we hit the bottom of the right stack, we just push a blank symbol onto the left.

https://cs.stackexchange.com/questions/2832/is-a-push-down-automaton-with-two-stacks-equivalent-to-a-turing-machine/2833#2833

Wikipedia defines "Turing complete" as:

  In computability theory, a system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be Turing complete or computationally universal if it can be used to simulate any Turing machine.

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

This thread makes reference to the alt stack, claiming that its presence makes Script Turing complete:

https://www.reddit.com/r/Bitcoin/comments/7yb3is/where_is_the_evidence_that_bitcoin_is_turing/duf1rt9/

That thread links to this thread, which contains the following:

  While it is a well known CS result that a two-stack push-down automata has the same power as a Turing Machine, Bitcoin Script cannot operate as a two-stack push-down automata. Even though Bitcoin Script has two stacks, Bitcoin Script doesn't have an associated finite state machine that you can create.

https://reddit.com/r/btc/comments/6hjxiy/new_craig_wright_interview_part_2_on/diz9g69/?context=3

In other words, there may be two stacks, but there's no way to sufficiently power them to create a Turing Machine.

Is Bitcoin Script Turing complete given the presence of the alt stack? If not, what specific functionality is missing?

You may be interested in a post I wrote. I wrote a Turing Machine (by utilizing the two stacks) and made a test transaction.

Basically if we assume that our program will halt, then it requires only a finite number of instructions, which is supported by the Bitcoin script. Unfortunately the Bitcoin script VM only allows a limited number of operations to be executed so only very short programs can be written in practice.


bcchanger.com: why are bitcoins being sold at 1/3 market value? Why are bitcoins being sold at 1/3 market value at bcchanger.com?

Are the lowball sellers trying to scam people or throw away money?

If you look at low price orders posting date, you will notice most of them are relatively older OR with zero feedback. The ones that with some positive feedbacks are genearlly in line with the price of the order posting date.

So it is more of a combination of old orders and scams.


How to fund a bidirectional payment channel? Assuming two users want to create a bidirectional channel between themselves such that user_1 wants to pay 2 BTC to user_2 at the end and he divides this amount into 10 micro-payment (each micro-payment = 0.2 BTC). And user_2 wants to pay 1 BTC to user_1 at the end and he divides this amount into 10 micro-payment (each micro-payment = 0.1 BTC).

So, the capacity of this channel must be 2 BTC + 1 BTC = 3 BTC. Logically, 2 BTC of channel's capacity must be provided by user_1 and 1 BTC of channel's balance must be provided by users_2.

However, since they create together only one channel between themselves, how can they manage capacity of this channel? (I think a payment channel has a single address with a single capacity, but here since the channel is bidirectional, its capacity must be funded by two users, so how can they establish this channel together with 3 BTC ? How can they share 3 BTC between themselves ?).

If you think that question is not clear enough, please let me know.

In your scenario you would like to create a payment channel with user 1 and 2 contributing (on-chain) and receiving (off-chain, in the payment channel) the following amounts:

User 1: 2 btc
User 2: 1 btc

To open and fund the channel accordingly, you therefore create the following funding transaction:

Input 0: 2 btc from user 1
Input 1: 1 btc from user 2
Output 0: 3 btc to 2-of-2-multisig(user 1 + user 2)

Before this funding transaction is broadcast, we also need a first commitment transaction, which captures the initial channel balance state you described:

Input 0: Spends 2-of-2 multisig output of funding channel.
Output 0: 2 btc spendable by user 1
Output 1: 1 btc spendable by user 2

(Each party receives an asymmetrically designed commitment transaction, but we will omit the differences for simplicity sake.)

Once both funding and the initial commitment transactions are signed, the funding transaction must be broadcast, to "secure" or "commit" the funds to the channel. The commitment transaction is only broadcast to close the channel and deliver the most recent channel state to the Bitcoin blockchain.

To answer your question, we now have an open channel, which is both funded by the two peers and reflects an initial channel balance according to the funding contributions (2:1 btc), which can be updated by revoking/updating the commitment transaction.


What is the transaction rate bottle neck? I recently read (Scalability link) that bitcoin can do 3.3 to 7 transactions per second...

I am curious, what is the bottle neck for the transaction rate?

Is it verifying the signatures? or maybe it's verifying sufficient funds?

My question is, what process is hogging the resources limiting the amount of transactions per second...

EDIT:

I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...

The answer to my question should be something like, verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.

I know several people have chimed in and said that it is the block size that is limiting the transactions per second, but that doesn't make sense to me, I don't see, nor understand, what block size has to do with transactions per second...

A block can hold no more than 1 MB of transactions. This sets the network's transaction speed limit.

A block is generated once every 10 minutes on average. We can calculate the block chain's write speed with:

w = s * g

where w is write speed MB/hour, s is block size limit in megabytes (1 MB/block), and g is the rate of block generation per hour (6 blocks/hour).

Plugging in the value yields:

w = 1 MB/block * 6 blocks/hour = 6 MB/hour

Converting to bytes/second, that's:

6 MB/hour * (1 hour/60 minutes) * (1 minute/60 seconds) * (1,000,000 bytes/1 MB) = 1,700 bytes/second

In other words, think of the blockchain as a hard drive. We can write to this hard drive at a rate of 1,700 bytes/second.

Even if we develop faster computers, we can't write data faster than this because the network rejects any block larger than 1 MB. We need to make some allowances for SegWit, but for now, let's keep things simple.

A one-input, one-output Alice-Pays-Bob transaction requires ~ 200 bytes. This is the absolute best case. We can, therefore, obtain an upper bound on the transaction rate using:

v = w / z

where v is the maximum transaction volume, w is the write speed calculated above (1,700 bytes/second), and z is the average size of a transaction (200 bytes/transaction).

Plugging in the numbers:

v = 1,700 bytes/second * (1 transaction / 200 bytes) = 8 transactions/second

  The answer to my question should be something like verification of sufficient funds per transaction input address takes 0.1 seconds, or as a whole verification of each transaction takes 0.3 seconds.

The network might appear to have a limit based on hardware or validation, but it does not. At least not directly.

As to why we should limit the block chain's write speed in the first place, the answer has to do with network security. Increasing write speed means:

data flows through the network at a higher rate;
more data must be stored by every node;
more transactions must be validated by every node.

Every node sends and receives every block, and every block must be stored. Increasing the blockchain write speed means that every node pays the price. Some won't be able to keep up, regardless of write speed.

Transaction validation is a resource hog due to signature validation and UTXO set manipulation. Storage space and bandwidth are also considerations, but less resource-intensive than validation.

Now, if you're asking why we have a 1 MB limit given XXX computer has such-and-such technical capabilities, that's the realm of the Never Ending Debate. Calculations have been done and simulations have been reported. They are not hard to find. They are, however, hard to believe given their wildly-differing claims and underlying assumptions.

The best thing I can recommend is to download a copy of Bitcoin Core 0.16.0 and try syncing a node from scratch. Report back when you're done.

The write speed limit we see is a compromise between inclusivity (more people using bitcoin) and security (difficulty of double-spending attacks). The limit may not have been set correctly, but figuring out where (or even how) to set it is exceedingly difficult. Not because of lack of ideas, but because of too many and lack of widely-accepted selection criteria.


How do exchange services provide forked coins to their customers for free? I know we can get forked coins by donating to ICO teams but I don't think the exchange services donte to them.
So I really consider how to get forked coins for free

Forked coins have nothing to do with ICOs.

You get forked coins by holding the coin that was forked from before the fork. After the fork, you will have the same amount of the original coin and the same amount of the forked coin. Exchanges who hold coins that then get forked will then also get the same amount of forked coins, as does anyone else. Whether they give you access to these forked coins is up to the exchange.

It may be technically difficult for them to do so so an exchange might not give you access to the forked coins. They may wish to keep the coins to themselves instead of giving free money to their customers. Without asking the exchange themselves, you cannot know why they didn't give you the forked coins.


What happens to bitcoin when Segwit2MB activates? Specifically what will happen with bitcoin in wallets. Do I have to try and quickly buy "Segwit coins" if the value of bitcoin core drops?
Do I have equal amounts of Segwit and core coins?
If so wouldn't that initially double how much I have assuming the value is the same initially?
Is it even a hard fork?

If the answer isn't relevant to Segwit2MB than what happened with Ethereum and Ethereum classic did it hard fork and I have the same questions about it.

Sorry if my terminology is poor

In the event of a chain fork, any Bitcoin that you have now before-the-fork will also exist after the fork on both chains. So if you have 1 BTC now before-the-fork and segwit2x activates causing a chain fork so there is segwit2x chain and non-segwit2x chain, then you will have 1 BTC on the segwit2x chain and 1 BTC on the non-segwit2x chain. However spending your 1 BTC on either chain can result in the 1 BTC on the other chain being spent too since the transaction would be valid on both chains because you are spending a coin from before-the-fork. This is known as transaction replay.


Adroid Blockchain wallet ver 4.0.12 recovery Just repaired my old Android phone, with Blockchain wallet version 4.0.12. It is asking for either the four digit PIN or the password, which I have both forgotten.
Is there any way to recover this now seven years old wallet?

Is there any way to recover this now seven years old wallet?

No.
This is because you probably ignored any advice to

keep somewhere safe a separate written note of your recovery phrase (seed phrase, backup phrase) or private key.

Make regular backups of important data on your computers (including on your phones)

Practise recovery from those notes and backups.

It is also because Android phones protected by PINs and passwords take measures to prevent thieves accessing your private data. As an inevitable side-effect, those measures also prevent you accessing that data if you forget your phone's PIN and Password and didn't make a written note kept somewhere safe.

I can open the phone, that PIN code I can remember. However, I do not remember the PIN code for the Blockchain wallet.

If you have access to the phone, and have some idea of what your wallet password might have been like, there are tools that may help you to sucessfully guess the password. These tools may take a very long time and not succeed.
For example https://github.com/gurnec/btcrecover says

Bitcoin wallet password recovery support for:
[...]

Blockchain.info

[...]


What are the most notable cases of Bitcoin scams? Bitcoins can be easily used to scam people out of their money due to the inability to perform charge-backs. What are the most notable cases of Bitcoin scams that are known?

Here's a list of the most notable scams, thefts, and hacks:
https://bitcointalk.org/index.php?topic=83794


Multiple addresses in transaction I am a total noob, so this might be a stupid question. I was looking at this transaction, and saw multiple inputs and outputs.

https://blockchain.info/tx/851e8c744494cd01070ca3723ec571137cc29558d1fd4b009bc81c3d75753540

What does this transaction mean? Who is sending to whom? Is this a multisig transaction? Why are there multiple receivers?

This is a normal transaction for an exchange paying out their users. The inputs are from user deposits and the outputs are for user payouts. It's very hard to know without a look at their database who owns which address, but this type of transaction is very common for large services like exchanges.

The reason there are so many inputs and outputs is that it's a lot cheaper for the exchange to send out 1 big transaction instead of many little ones.


I heard a message was encoded into the blockchain, how can I read it? I have been running a few full Bitcoin nodes for a long while now and I've decided to start learning how to interact with a node to get different information. Recently, Elon Musk's two messages were added to the Bitcoin blockchain. I wondered if as a starting pointI could directly interact with my BTC node and extract information like reading these two messages?

I saw this tweet in which it was mentioned that F2Pool included a message in coinbase transaction related to Elon Musk's tweet: https://twitter.com/zackvoell/status/1355152428903985157
Block: 668197
Use the below commands to get the message:
getblockhash 668197
getblock 000000000000000000023c31edf49adb2306d0db74e6f1f032ef76deaa7a464a 2
The first tx that you see in the JSON results will have a coinbase value which can be converted from hex to ascii using https://www.rapidtables.com/convert/number/hex-to-ascii.html
Or you can use this command on Linux which uses jq and xxd to make it easier:

bitcoin-cli getblock `bitcoin-cli getblockhash 668197` 2 | jq -r '.tx[0].vin[0].coinbase' | xxd -r -p

It was mentioned by Sjors Provoost in https://twitter.com/provoost/status/1345726239676489728
Can be verified by comparing with the things that you see for block 668197 on a block explorer: https://bitaps.com/668197


Why guiminer is using different amount of GPU each time I restart my copmuter? Why guiminer is using different amount of GPU each time I restart my computer?
I'm running guiminer-20121203, NVIDIA GeForce GTX 670M, poclbm.exe with flags  -s 0.005 -f 60
What I noticed was, it was 35Mgash/s with 75% GPU usage. And after I restart my computer, it became  50Mgash/s with 100% GPU usage with the same flag settings.

Also, before when I tried only with flag -s 0.010 it utilized 100% GPU, but without restarting computer, using flag -s 0.011 reduced GPU usage to 60%.

What's going on??

Other applications can alter your GPU settings not just guiminer.

If you take a read over this question here it may reflect a similar circumstance which is causing a variable hash rate on your hardware. Without knowing your exact usage of your computer though I cant say for sure.


How many times of validation needed for a whole payment transication? I try to figure out it. So far, I believe there are 3 times, in wallet before broadcast, before accept to mempool by node, before accept a new block created by other node. I don't believe it's all. Maybe before mining to construct a new block need a validation. Anybody clear about it? What's the different for those validations?

In theory, a transaction is validated before it is sent, when a transaction is accepted into a node's mempool, when it is selected for inclusion in a block, when the block is verified before being broadcast, and when it is in a block that is received by a node. However, there really is no need for doing this validation multiple times because the same validation is done every single time.

So instead many node software will validate the transaction only when it is received in the mempool and only keep valid transactions in the mempool. When a new block is received, the transactions that were in the mempool need to be removed from the mempool, and because it knows that those transactions were valid because they are in the mempool, it does not need to re-validate the transactions from the block. The only transactions that need to be validated in the block then are the new transactions which the node did not have in its mempool.

For miners, the transactions they select will be from the mempool which only contains valid transactions. Thus this removes the need to validate transactions before selection and after block creation.

Additionally, the node can cache validation results for invalid transactions so that if it sees such transactions in a block it can look up the result in the cache instead of re-validating the invalid transaction. They can do this for valid transactions too to skip some validation steps.


What's the best Android wallet client for bitcoin? There are many bitcoin wallet clients on android market. What is the best considering security, interoperability and usability?

If you want to keep your private keys secret (on your phone, that is), I'd recommend

Bitcoin Wallet for Android

The app also does not imply any trust in single servers, as it manages the block chain on-device.


A hashrate of 1.42 EH/s, really? According to http://bravenewcoin.com/news/number-of-bitcoin-miners-far-higher-than-popular-estimates/ there are 100,000 miners and blockchain.info claims a hashrate of 1.42 EH/s.

How is it possible to be mining on Bitcoin at a hashrate of 1.42 EH/s with just 100,000 miners?

That would yield 14.2 TH/s per miner, while best ASICs are performing around 1 TH/s https://en.bitcoin.it/wiki/Mining_hardware_comparison

A miner should not be correlated with a device. I can have 10 devices and I will still be a single miner from the perspective of the pool. I can have a mining farm with thousand devices and I can still look like a single miner to the pool.

Also note that a miner, in the above sense, is just a person that provides hashing power to a pool that runs a mining node; i.e. there are much less mining nodes.


What does it mean that fork is required? In bitcoin related discussions people often say that something may require a "hard fork".
What do they mean? What is a fork?

Fork means in this context that devs are about to change some fundamental hardcoded rule. This may mean that the part of network which didn't upgraded client to new version will run on one set of rules and another upgraded part of network will run on other set of rules. In general, network fork means inconsistency of whole network.


How is a transaction verified in a micropayment channel? Let's say Alice opens a micropayment channel with Bob and sends $10 into the multi sig transaction.

How do we know that Alice has those $10? Or are we taking the risk of her double spending it?

In the process of opening a micropayment channel, the two parties put funds into a lock-box of sorts that requires both parties to sign off any any withdrawals from that lockbox. In the blockchain, this is essentially putting some funds into a 2-of-2 multisig output, where the 2 keys are Alice and Bob's keys. If only Bob is going to be transferring money to Alice or vice versa (unidirectional), then only one person need put funds into the 2-of-2 lock box.

Then, when it comes time for Bob to pay Alice, Bob gives Alice a transaction that spends the contents of the lock box, giving Alice some amount of the lock box funds and using a change output that puts the change back into the lockbox. Since withdrawing from the lock box requires both Alice and Bob to sign off, Alice can confirm when Bob has signed off to give her funds.

Notice that it has to be this way, requiring both Alice and Bob to transfer funds through the channel, because if it just required the sender of the funds, you run into the exact problem you mentioned: the sender could be trying to double spend those funds and you wouldn't know.


opening an old wallet.dat I had about $8 USD worth of bitcoin in a wallet, and I backed up the wallet.dat to my dropbox. According to the modified date of the file this was in April 2013, so it was probaby from bitcoin qt version 0.8.1, or maybe a little earlier.

I basically left it there and haven't done anything with bitcoin since then. Since it is worth probably at least $100 now I decided to check the exact amount.

I downloaded the latest version of bitcoin core, added the wallet.dat file to the data directory, started it with -rescan, and waited almost a month (!) for the blockchain data to get up to date. The balance showed as 0 the whole time. I thought it would update once the blockchain was totally downloaded, but it still just says 0.

Is this a problem with old vs new versions? Did I do something wrong? Next time, should I expect the balance to show a non-zero amount even if I haven't downloaded the whole blockchain yet?

I recently recovered an old wallet.dat file using pywalley.py and Electrum, which allowed me to read the wallet and sweep the coins to a new Electrum wallet.
Steps:

Get the jackjack pywallet https://github.com/jackjack-jj/pywallet
Put the wallet.dat in that directory
./pywallet.py --dumpwallet  --datadir=. --passphrase=PASSPHRASE

Passphrase is optional, only if the wallet is encrypted.
If that works, then run it again with the --dumpwithbalance option, that is
./pywallet.py --dumpwallet --dumpwithbalance --datadir=. --passphrase=PASSPHRASE
Ideally, redirect it to a file. Then, search the file for nonzero balances.
You can use http://BitRef.com to make sure that the addresses with balances still have balances.
In the JSON dump of the wallet.dat file, you will find the private key, in the field labeled "sec." Don't share that with with anyone. That key will allow anyone to sweep your bitcoins into their wallet.
Using that key, you can install the Electrum wallet and sweep the coins into a new wallet without downloading the blockchain. You will pay a fee of 0.2-0.5 mBTC to do it slowly, more if you are in a hurry.
There are good instructions at https://en.bitcoin.it/wiki/Transferring_coins_from_Bitcoin-Qt_to_Electrum which include a link to a more paranoid process using an offline computer to avoid accidental exposure of your private key.
There is a default fee of 0.5 mBTC, you can adjust it in Tools-->Preferences.
The address in the "Sweep" dialog box is just the new wallet address being swept to.
You can watch the transaction progress at http://bitref.com or http://blockchain.info.
Once in the new wallet, you can send to an exchange like CoinBase to cash out, or just spend the Bitcoin. The Electrum wallet costs more in fees but saves you the pain of downloading and managing the whole blockchain.
EDIT #1: The sad news is that as of January 2018 the transaction fees are hovering around USD $40, so recovering a small wallet will probably consume all of its value. I managed to sign a low fee transaction from my old wallet, but it has been stuck in the mempool for weeks, now. It may be there forever.
EDIT #2: After 26 days in the mempool, my low fee bitcoin transaction finally got confirmed.


Bitcoin Transfer from Coinbase to Zebpay in India I have one friend in Canada and i want to buy bitcoin from canada and get in to zebpay wallet in india. I had completed 100 Canadian dollar transition yesterday, but when he was buy 100 Canadian dollar in coinbase account using credit card. Then he had got 96.69 something. and When he was send me 9 Canadian  dollar then 4.94 Canadian dollar charges and again send me 75 Canadian  dollar then charge is 4.99 Canadian dollar.

So i want to know how to calculated fees and how can i pay minimum fees on bitcoin transfer to zebpay wallets.

What is fixed rate or variable rate in bitcoin transfer ?

Please tell me as soon as possible.
Thanks in Advance.

It is important to differentiate between mining fees paid to the Bitcoin Network and service fees charged by a middleman company such as Coinbase or Zebpay.

The Bitcoin network fees are market based (when demand goes up for space in the block, the fees will go higher) and are based on the amount of data in the transaction, not the amount being sent.  A 0.1 BTC transaction can have higher fee than a 1000 BTC transaction for example.
The fees charged by payment processors, exchanges, etc are usually based on the amount sent. Coinbase used to be 1% for example.  Normally receiving money is free, but sending or converting to/from fiat cost something. You need to check with the services you are using.

If you own the bitcoin keys (you are using a wallet like Electrum, Mycelium, Bitcoin Core, etc), then you only pay the network (miner) fees.  If you are using a service like Coinbase, you may be charged a fixed fee by the service, and / or the network fee.


Electrum wallet file Are all the information of my wallet stored inside the wallet file that I can find in the folder "wallet", inside the .electrum folder?

For instance, I can copy this file on another pc and just paste it into the "wallet" folder to have access to my BTC again, right?  (assuming that I know the wallet password)

I know that I can restore the whole wallet with the master seed, I was just curios if this method works also.

Yes. All of the information about your wallet is stored in the file of the same name as your wallet in the wallet folder of the electrum datadir. Copying that file elsewhere will allow you to keep all labels and comments on your addresses and transactions.