BitInstant - How do I trade my plain cash for Bitcoin at CVS, 7-11, Walmart On the BitInstant site, it says that I can trade in my paper money at places like CVS, 7-11 and Walmart and get bitcoins sent to me in the next 30 minutes. Can some explain how this works and what I have to do. Do I just go up to the clerk a 7-11 and hand him my invoice i recieved at BitInstant.com and I will get my bitcoins?

BitInstant has teamed up with an already-existing payment processor. This payment processor is designed to allow those without credit cards make purchases online. The way it works is that you make your purchases, check out, and a special receipt is generated with a transaction ID. At this point the transaction is in a "pending" state, awaiting payment. You take that receipt to a participating location (thousands worldwide), they check the transaction ID from the receipt and your cash and then finalize the transaction.

Purchasing bitcoins via BitInstant is really no different, except that your "cart" contains Bitcoins.


Isn't Bitcoin's hash target supposed to be a power of 2? From Bitcoin's whitepaper I've gathered that the hash of a block must start with a certain number of zeroes. And that this number of zeroes is adjusted every 2 weeks. Consequently the hash target is a power of two.
Requiring an extra zero for the hash function will divide the hash target by 2.
With that being said, in another question on the exchange (How is difficulty calculated?) it appears that the difficulty can be multiplied by fractions (e.g. 40%).
Does that mean that the hash targets aren't necessarily powers of 2? Or is the target rounded to the nearest power of 2?

Contrary to popular belief, the target is not actually based on the number of leading zeroes. This is a major simplification that is used to get the general idea across, but is not actually how the code works. Instead, the target is just a number that is adjusted by the ratio between the actual time between blocks and the expected time between blocks (with an off by one error which actually causes it to not quite work as expected). So the targets are not necessarily multiples of 2.
There is one additional caveat - the new difficulty can only be at least a quarter of and at most 4 times more than the old difficulty. The multiplier (the ratio between times) thus must be between 1/4 and 4.


RPC connection fails after too many queries I'm building a node.js app that uses a json-rpc connection to fetch information from the bitcoin daemon.

It works great, except every once in a while, the RPC connection "fails." It goes down for anywhere from 1-20 seconds. Querying it via the command line gives the response: error: couldn't connect to server. I have built in an error handling mechanism that waits a progressively larger amount of time for each unsuccessful connection, and it works well.

My problem, is over the course of progressively scanning the blockchain, over half of the running time is spent waiting for the daemon to come alive.

My thought was maybe its my hard drive/something with my computer, so I moved it to an ec2 instance (specifically c3.2xl) and moved the blockchain to the SSD. This actually increased the amount of time waiting versus running the node app locally.

Has anyone experienced this before and came up with a solution?

I haven't had this issue before and I've been spamming my RPC pretty hard.

Does your bitcoind already contain the whole blockchain or is it still updating?

There's a debug.log and db.log in the bitcoind data directory, I guess those will tell you what's wrong.


Is it possible to adjust transaction fee amount in MultiBit Classic? I have a few transactions I made with MultiBit Classic 0.5.17 stuck in the unconfirmed land for days now. They all have a transaction fee of 0.0001BTC as that is the only way my version of MultiBit sends payments. I do not see a way to adjust the transaction fee. Is there a way to adjust a transaction fee in MultiBit Classic 0.5.17? If not, what do I do with coins stuck in unconfirmed transactions? What do I do with coins in my MultiBit Classic wallet? If there is no way to adjust the fee, how can I move them out of there with any hope the transaction will get confirmed?

It's been a little while and I have not gotten an answer here, but I figured it out myself and would like to post the answer to my own question here so it can help someone in the future.

The answer is NO, you can not adjust transaction fee amount in MultiBit Classic. It is only possible to send bitcoin with 0.0001btc transaction fee. This is outdated software and was hard coded to that amount.

What I did to deal with that is I imported my private keys from MultiBit Classic into Electrum, which not only is able to adjust the transaction fee, but also makes pretty good suggestions as to what the fee should be at the moment based on the data it collects from the network.

To export the keys you need to make them visible and that is not secure unless you are in a safe environment of your home, etc. After importing the keys to Electrum I was able to access that wallet and spend the coin to other places, which was my plan to begin with. You can always destroy the files with plain text keys by electronically shredding them (deleting does not destroy files beyond recovery). This is what I did.

Hope that helps someone in this situation in the future.


Why do some pools require a worker name with an underscore and others require a period? The majority of pools I see that they use a period such that:

username.workername

others use:

username_workename

I see that it definitely is not interchangeable.  How come some pools use underscore (such as bitminter and btcguild)  and others use a period (like gigahash.io)?

These are just arbitrary rules. Made by the pool admin. Really doesn't matter.


Trouble compiling bitcoind on OSX with homebrew I've read the README on the bitcoin github page which instructs you to install the following libraries using MacPorts - boost db48 dbus openssl.
I have these installed using homebrew which I use instead of MacPorts. They are also the correct versions as homebrew installs, later, incompatible versions.
With these installed I edited the make to point to the libraries homebrew installed namely DEPSDIR=/usr/local and adding  -I"$(DEPSDIR)/Cellar/berkeley-db4/4.8.30/include" to INCLUDEPATHS
However I'm getting this compiler error which is cryptic to me:
https://gist.github.com/ashleyconnor/944f611b969444f06430145972b880cf
Has anybody managed to get this working?

Update: These instructions or similar are included in the bitcoin source as of 19 February 2013. See doc/build-osx.md for details. As such, the below instructions may fall out of date. Alternatively, make it easy on yourself an use WyseNynja's homebrew tap with brew tap wysenynja/bitcoin && brew install bitcoind.

Building bitcoind on OSX 10.8 with homebrew

I got bitcoind working using these instructions. For reference, I'm on OSX 10.8.2 with homebrew 0.9.3. I've made an assumption throughout that homebrew is installed in /usr/local. I've also assumed that you've installed the Xcode command line utilities and any other packages that are essential to building code. If you build any code regularly, e.g. you have RVM installed to build ruby occasionally, you're probably OK!

Install some necessary libraries from homebrew.

brew install boost miniupnpc openssl

Revert berkeley-db formula to an older version

cd /usr/local
git checkout e6a374d Library/Formula/berkeley-db.rb

You may have to unlink it if you've already installed the latest version.

brew unlink berkeley-db

Install berkeley-db 4.8 now that you've got the right formula in place.

brew install berkeley-db

Checkout from Github.

git clone https://github.com/bitcoin/bitcoin.git

Edit the makefile.osx to change it a bit. Here's a diff that shows what you need to change, or you can just use this as a patch by doing echo '$patch-text' | patch, where $patch-text is the patch text below.

diff --git a/src/makefile.osx b/src/makefile.osx
index 9629545..ffac9a3 100644
--- a/src/makefile.osx
+++ b/src/makefile.osx
@@ -7,17 +7,19 @@
 # Originally by Laszlo Hanyecz (solar@heliacal.net)

 CXX=llvm-g++
-DEPSDIR=/opt/local
+DEPSDIR?=/opt/local

 INCLUDEPATHS= \
  -I"$(CURDIR)" \
  -I"$(CURDIR)"/obj \
  -I"$(DEPSDIR)/include" \
- -I"$(DEPSDIR)/include/db48"
+ -I"$(DEPSDIR)/include/db48" \
+ -I"/usr/local/Cellar/openssl/1.0.1c/include"

 LIBPATHS= \
  -L"$(DEPSDIR)/lib" \
- -L"$(DEPSDIR)/lib/db48"
+ -L"$(DEPSDIR)/lib/db48" \
+ -L"/usr/local/Cellar/openssl/1.0.1c/lib"

 USE_UPNP:=1
 USE_IPV6:=1

Start the build.

cd bitcoin/src
make -f makefile.osx DEPSDIR=/usr/local

It's now available at ./bitcoind. We have to first create the rpc configuration file, though. Run ./bitcoind to get the filename where it should be put, or just try the below text.

echo "rpcuser=bitcoinrpc
rpcpassword=HdAseQSRkirfoNuUSzqzixyL9sM1T6ABfzV1nyNmbuwg" > "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"

When next you run it, it will start downloading the blockchain, but it won't output anything while it's doing this. This process may take several hours.

Mine appears to be working fine, but it's still downloading the blockchain. I'll be able to tell after some testing if it's working normally or not, but I suspect that it is!

Inspirations:

https://github.com/WyseNynja/homebrew-bitcoin/blob/master/bitcoind.rb
What are the steps in building bitcoind on Mac OS X 10.6?
Trouble compiling bitcoind on OSX with homebrew


How can I clone bitcoin 0.16.1 version (not the latest one ) with git command this is the version that I want to clone :

https://github.com/bitcoin/bitcoin/releases/tag/v0.16.1

You cannot directly clone a tree you have to first take the full repository then checkout the commit you want.

For the 0.16.1 version execute these commands in a shell:

git clone https://github.com/bitcoin/bitcoin
git checkout dac5d68

more informations here: https://stackoverflow.com/questions/43411941/i-cannot-clone-git-tree


Whats the public key required for in a transaction? In figure 1 of the original paper by satoshi, why include the public key of the next owner in the hash?

The public key belongs to, and identifies, the recipient of the funds. Without it, the network doesn't know who the money goes to, and the rightful owner can't use it.


Coinbase to Coinbase off-chain transaction fees? When I click on "Send" from my bitcoin address which I know is off-chain in Coinbase to another Coinbase address which I also know is off-chain. So technically the transaction will not touch the blockchain, just update their off-chain books locally.

I know it's off-chain, because I deposited money using my credit card, and I scanned all addresses under Tools > Addresses on a blockchain explorer for a few days and there's nothing in there. They're keeping it off-chain until I actually want to spend it. Granted, but if I spend it to another Coinbase off-chain address, they should be able to find out that this is an address they own and they don't need to utilize the blockchain at all and could do it all off-chain as they own both addresses.

If that's the case, why is coinbase still charging me network fees? Sounds like mickey mouse fees to me for updating a record in their database without touching the blockchain.

Are they assuming that I don't know it's a fully off-chain transaction, and think they can charge me regardless? Or does their wizard have a glitch ?

Does Coinbase pay miner or network fees when sending digital currency? is stated clearly here "Any transactions sent between Coinbase customers by email address take place off-chain (not on the blockchain) at no cost".
 Maybe Coinbase have a system that charges network fee as long as "addresses" are used.


Anonymity versus trust Bitcoiners seem to love to talk about anonymity. But to me, anonymous transactions are far from Bitcoin's greatest strength. And to some, the need for high anonymity is the first sign that someone is "up to no good".

But what happens if you need to the opposite? I find myself in a situation where I had listed a bitcoin donation address on my website, but someone was able to deface my website and put another adress in instead.

Now, of course this is a special situation, and since I don't know my adress by heart, it went on for a bit before I noticed this.

What got my mind buzzing was when I put my real adress back up, and a person asked me "How can I be sure this is really your wallet?"

The question is, how can I prove that I am on the other side of the bitcoin address on my public website? Sending screenshots is a bit impractical, and honestly doesn't really tell me much. Is there a way to do some kind of handshake with the recipient or in any way verify the identity of a bitcoin address?

I know this is directly against the core principles of anonymity, but a currency will still need trust for commerce to flourish, and I am curious if there is any method one could use.

Right now, I'm juggling the idea that the user sends a microtransaction with a 6 digit code, and the recipient tells the sender the code when it appears in my wallet. This is inspired by mobile bluetooth trust syncs. But there must be an easier way. I imagine a very high level of ingenuity among the Bitcoin community, any ideas what could solve this?

If your idea is based on "theoretical software" (something that could be made, but simply hasn't) I'm willing to hear you out as well.

If you have a secure channel to the recipient or some way to identify communications as coming from the recipient, just have them send their Bitcoin address. If you have no such channel or method, it's obviously impossible. What can you do to prove your address is yours that I can't do to prove my address is yours?


Having an address without a wallet If somehow I have an address with its corresponding private key but I have no wallet (well maybe I use some wallet to generate the address/key and then throw it), would it make sense to collect coins to that address and in the future redo the wallet with the addr/key to handle them?

Does that make sense? I am thinking of it as a security police to not have a wallet on a computer (neither connected to the net or not)

Absolutely! Generate your public and private keys using a wallet, save your keys somewhere, you can even print them on a paper and put it in a save place. I think this is the higher level of security.

Additionally you can split your coins in 10 wallets and print them separately. That way if you need only 0.2 bitcoins you can take two keys and import them in your wallet. This gives you flexibility.


How would changes to the Bitcoin protocol be decided upon? What constitutes a "majority"? We know that the Bitcoin protocol can be updated at any time. Larger updates and hard forks can be difficult to push through, but as long as a majority of the Bitcoin community supports the update, it can happen.

However, it's unclear to me exactly what "majority" means. Which players have the most weight in the decision-making process?

Does it mean "a majority of holders of bitcoin"? If an update is so drastic that it would threaten confidence in Bitcoin, they would likely sell and would vote with their wallets. However, if the update isn't particularly drastic, currency holders would likely have no course of action. If they only use Coinbase, for example, they don't have a choice of which version of the protocol to use.
Does it mean a majority of people with software running a version of the Bitcoin protocol? Currency holders with wallets like Bitcoin-Qt? They decide which version to run.
Does it mean a majority of nodes? (This is distinct from #2, as a person running 10 nodes in this scenario would get 10 votes instead 1 vote). Someone can flood the network with nodes running the protocol, and if there is a hard fork, people may mistakenly check to see how many nodes support each version, basing their decision on that ratio.
Does it mean a majority of merchants? They can decide whether to continue accepting Bitcoin, and they decide whether to convert BTC immediately or to continue to hold it.
Does it mean a majority of mining power? The miners are the ones who decide which blocks to accept and work off of.
Does it mean a majority of the developers (weighted by their influence)? Some have pointed out that that Gavin has a lot of influence and could probably convince people to adopt a particular change, as long as the change is small enough. Are there ways for the developers to  surreptitiously exert control over the progression of the protocol?

I started wondering about this after I read the following question: How could the bitcoin protocol be changed? Has this ever occurred?

In the comments, @Muhd says:

  So it follows that changes will likely only be implemented and adopted if it benefits a large majority of participants. I suppose most security updates would qualify. Technically, isn't it the case that we only need a majority of miners (>50%) to switch over? Or does it require more than that?

@meni-rosenfeld responds:

  No, a majority of miners is irrelevant. If miners try to change the protocol on their own, they will simply be ignored by the rest of the network, and their "mining rewards" will be worthless. A change requires an economic majority - adoption by the users and businesses who give the currency value.

P.S. This question is important because there are certain protocol changes that would be good for some parties but bad for others. For example, increasing the block size would be good for payers, but bad for miners (it would be easier to get a transaction in the blockchain, so there'd be lower mining fees).

"...if it benefits a large majority of participants.", nobody proposes anything ever that will not, at least be presented as, 'benefiting a large majority of participants'.  From 'trickle down economics' to 'you might not agree now with me on this proposal, but you'll agree with me later' gives the people that set the agenda and write, defend and prepare these proposals and technical changes a lot of influence.

secondly, normal politics (as this is politics, not engineering primarily, as for instance now BIP16 and BIP17 are evaluated for implementation and the developers do not agree and seem to have valid points.)

Although i don't get the impression that the bitcoin developers have dark motives, or don't want the best, i am worried about what is going to happen when the US government starts to try to exert influence over bitcoin. There are already BIP proposals that for instance make it possible for someone to request a payment from a customer, and this greatly reduces anonymity but increases tracability vs. for instance the implementation of zerocoins which would build in automatic mixing and increase anonimity. the US govt, or any government for that matter will use their influence and also power to try to safeguard its (perceived) interests. (i don't know which BIP's these are - but you get the picture)

Actually, if i am not mistaken there is no bitcoin protocol as such, there is just the bitcoin-qt client, a piece of C++ code that is hard to understand (unless you're a C++ programmer) and by the sound of it not unambiguous. This is the protocol, the protocol is written according to how this program works.

Anybody has any illuminating thoughts or facts on this issue?


How to update and older version of electrum on ubuntu 17? I used the following commands to install electrum:

sudo apt-get install python3-setuptools python3-pyqt5 python3-pip
sudo pip3 install https://download.electrum.org/3.0.5/Electrum-3.0.5.tar.gz

For latest tar files: https://electrum.org/#download

In the future, how would I go about updating electrum? What command would I use to update?

Also, where are the electrum files installed that contains my private keys and wallet?

how would I go about updating electrum? What command would I use to
  update?

There are couple of ways to do it:

If you downloaded the official package (tar.gz), you can run electrum from its root directory, without installing it on your system; all the python dependencies are included in the 'packages' directory. To run Electrum from its root directory, just do: ./electrum
There is also PPA package repository, but I think they didn't update it.
I've a shell script, this script check the github source, download the last version and save the backup of an old wallet. You can find it here.

  where are the electrum files installed that contains my private keys
  and wallet?

On the Linux machine, there is the folder ~/.electrum which contains your wallet, configs and other.


How does first seen replace by fee work? This pull request describes first-seen replace-by-fee. How is it different from normal replace-by-fee, and how does it compare to child-pays-for-parent?

Right now, for the most part, Bitcoin miners follow a First-Seen-Safe rule: If 2 conflicting transactions show up in the mempool, the miner sticks with the one it saw first.

Replace-By-Fee would enable miners to remove transactions from the mempool based on which transaction pays the higher fee. This is problematic because it enables fraud. If I pay a merchant and walk out, I can then easily broadcast a conflicting transaction which sends the money back to me with only a slightly higher fee. The merchant doesn't get paid, but I get the goods for a slightly larger transaction fee.

With Child-Pays-For-Parent, an unconfirmed transaction(parent) can be raised in mining priority by spending their output(children). The extra fees that would come from children offer incentive for the miner to include the parent transaction. CPFP relates to RBF as a way for a merchant to fight fraud. If a merchant detects that a payment they were expecting has been rerouted, they can raise the priority of their preferred transaction using CPFP. This is a contentious solution to make RBF acceptable.

First-Seen-Safe Replace-By-Fee follows the RBF rules, but puts some requirements around replacing transactions in the mempool. When replacing a transaction based on higher fee, all the amounts of all the outputs from the original transaction need to be met. You can add and remove inputs, increase past output amounts, and add new outputs. You are allowed to modify transactions as long as you meet or exceed the past outputs.

With FSSRBF you can safely accept transactions that spend confirmed outputs, but not unconfirmed transactions spending outputs of other unconfirmed transactions. CPFP is useful beyond RBF, but is not necessary for FSSRBF usability.


How to receive funds in LN http://lightning-wallet.com/using-lightning-wallet#receiving-lightning-funds

This link states that:

  Nothing can be received once a fresh channel is created since a room for incoming funds should be first made by spending.
  A payment channel can be thought of as a full bottle of water: in order to pour something in one first has to pour something out.

If correct, how can you ever receive anything?

The currently lightning specification means that one party must fund the channel. So if A opens a channel with B and A is funding with, e.g. 1 BTC, then the channel initial state will be A:1 BTC, B:0 BTC. So A can't receive anything because B is the only person that can send money to A, but B has no money. However B can receive money from A because A has the funds. Once A has sent something to B, A can then receive funds from B. So it isn't that no one can receive funds, but rather that initially only one party can receive funds until an initial send is made.


I would like a wallet that lets me export my private keys Multibit classic allows you to export private keys.  Apparently Multibit HD no longer allows this  (is it true?  I'm pretty sure).

I want a wallet that lets me export my private keys.  So I don't have to depend on any specific software program.

I'm not sure I trust Electrum doesn't it rely on it's own network of servers?  I don't want to rely on any specific servers.

Seems like the only way is to get Bitcoin-QT client and have the whole darn blockchain which I have to keep updated.

Does anyone have any suggestions.  I'm starting to think Multibit classic is the only one that can export private keys without needing the whole blockchain.

Try it with JAXX wallet, I think there you're getting your keys


Can someone explain me ECDSA (creating public from private key) with 8-bit numbers? Trying to understand Elliptic Curve maths with 256-bit numbers seems like hard to explain/understand. I wonder if by lowering down the possible numbers get's a little bit easier.

It's my opinion that mechanical explanations of ECC are almost completely worthless to people, and mostly just generate false understanding.  Exactly how two points get added to each other isn't an important thing to understand in order to understand ECC any more than understanding van der waals forces is important to someone trying to oil paint. So my advice is to find explanations that talk about the abstract algebra of ECC rather than the mechanics of group operations. :)

But some people just love the mechanics.  So if you must, find a tutorial that uses secp256k1 (the 'bitcoin' curve) and replace the field size P  with 79 (so you would be doing arithmetic mod 79 instead of 115...663), and N with 67 (instead of 115...337).  'a' stays 0, 'b' stays 7. For G you might choose {60, 10}.

The resulting curve should have all the same algebraic properties as secp256k1 (except for being discrete log insecure due to being so small). To check your math, G * 29 = {37, 10}. Meaning that the pubkey for private key 29 is the point at {37, 10} with the above parameters.


What makes the block time of a certain coin shorter than the other? What are the factors that impact the block time of a certain coin? Is a shorter block time always better or there's a trade off?

The block time is determined by each coins mining rules. In particular how difficulty is adjusted from time to time. Bitcoin adjusts the difficulty so that the expected time to mine is 10 minutes but a coin can adjust the difficulty to aim for any time.

Aiming for a very high time is inconvenient as users must wait longer to have a transaction included in a block. Using a short time increases the risk of orphans where two miners find the same block at once.


Why does it take a different time to generate a different pattern of the same length in vanitygen? I've been looking at generating some vanity addresses today, and I found it surprising that the program generating the address predicts that it will take a different amount of tries to compute a vanity address of the same length, but with a different pattern. For example, generating "11..." takes 256 tries, while "12..." takes 23. Shouldn't it takes the same amount of tries to generate both of them, or am I missing some important detail?

Each leading 1 in an address after the first 1 represents a leading zero byte in the 160 bit hash of the public key, and so makes the search 256 times harder.  See the wiki page for Base58Check encoding for details.  Whereas any other character makes the search only around 56 times harder.

Every version 0 bitcoin address begins with a 1.  And 1 in 256 of them begin with two 1's.  However, I don't know where the 23 comes from.  Perhaps it's a result of Benford's law - we're changing to base 58, and so can expect more addresses to start with '12' than any other 2 characters.

To see this, suppose there were 256 addresses, from 0x00 to 0xFF, and that we converted them to base 10 to make addresses.  There are 256 different addresses, and 111 of the 256 begin with a '1' (1, 10, 11, ..., 19, 100, 101, ..., 199).  In bitcoin's base58 encoding, value 1 is encoded by character '2'.

Edit: the above is kind of convincing until you see that:

'12' through '16' all have difficulty 23,
'17' through '1P' have difficulty 22,
'1Q' has difficulty 65 and
'1R' through '1z' have difficulty 1353.


Generating addresses on the fly or pre-generate and store public key? When running a service that needed a bitcoin address, would it be better to generate a new address to use at that moment and store the private key on your server, or would it be better to pre-generate say a million addresses and have the private addresses already stored offline?

The later would be combined with a backup option to generate on the fly if its address pool dried up.

To answer this question accurately, we'd really need to know more about how these new addresses will be used in your service.

If these newly-generated addresses are to be "deposit only", that is, as long as you're not needing to send coins from these addresses, then the most secure option by far is to generate the addresses offline and keep the private keys offline.  This is pretty obvious: cold wallets are almost always more secure than hot wallets.

Unfortunately, most services will need to access the private keys of newly-generated addresses for some reason, if only to send any Bitcoins received to another wallet.  In this case, the next best option is to maintain as low a balance as possible in these addresses.  That is, as soon as they receive any coins, forward the balance as soon as possible to an address that is stored in a secure, offline wallet.


Who controls the Payment Hub in tumblebit? Who controls the "Payment Hub" in tumblebit?

Is it another protocol or company or is there something else / someone else involved?

The notion is that anyone with sufficient Bitcoins to act as collateral for the payment channels could setup a TumbleBit payment hub. This would likely be a company.

The more users a TumbleBit payment hub has the greater the privacy and utility offered so one would expect a small number of payment hubs with many users.


What is the maximum throughput of the Bitcoin network? (2013) I have heard that the maximum block size means that the Bitcoin network has a maximum throughput. What is this maximum?

The current block size limit is 1MB, but this is likely to be changed in the future.

Transactions are about 500B, so the current limit is 2000 transactions per block, or about 3 per second.


In macOS build instructions for Bitcoin Core, why do they recommend creating RPC configuration file? In this file

https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md

  Before running, it's recommended you create an RPC configuration file.

Why?

I believe this suggestion is dates from before cookie authentication existed, and is not needed anymore.

Before, it was impossible to use the RPC protocol to send commands to a running bitcoind/bitcoin-qt instance if no username and password were configured.

Since the introduction of cookie authentication, this is no longer needed.


Litecoin tagged addresses I know that on blockchain info there is a list of bitcoin tagged addresses https://blockchain.info/tags. I'm wondering if there exists something similar for Litecoin, since I did not find any information about it.

Those tagged addresses are only for blockchain.info. They are not part of the Bitcoin blockchain, they are local only to blockchain.info. So you would need a service like blockchain.info that maintains a database of addresses that are tagged, but those tags would only apply to that service only. AFAIK, there is no such service.


Is it safe to authorize Coinbase to withdraw cash directly from my bank account? I wanted to buy Bitcoin. Coinbase said that they could transfer money directly from my U.S. bank account and convert it to Bitcoin, and then I'd have a Bitcoin address and could give people Bitcoin or pay with it for things. I went ahead and signed up and requested a transfer of $100.

Here's why I am worried: Coinbase asked me to provide my credentials to my online banking while I was on the Coinbase website, both my username and my password. I thought that should have happened on my bank's website with SSL connection, not through Coinbase. I went ahead and did it but now I'm worried. Coinbase said that the transaction wouldn't go through until January 6, 2016 because of ACH and the holidays, which is fine. I'm just worried because I have several paychecks worth of money in that bank account.

(I did not access Coinbase from Android or any other mobile device. I used my desktop PC with Google Chrome web browser.)

They don't  need your password to process the ACH in the future. this sounds like they used your banking credentials to verify that it really is your account. You should be able to change your password on your banking account now and be safer.


Blockchain API whitelist all IP addresses I am currently trying to implement the blockchain API in my application. I have done this successfully however, I am having trouble whitelisting IPs. Each time a user accesses the app with a different IP,they get an error. Therefore I have to manually approve that particular IP address. Honestly, this is a major pain. How can make it so that I do not have to approve each and every user's IP address? Is there a wildcard for all IP addresses in the world that I can use?

Use this: %.%.%.%

It mentions this in the IP Whitelist section, found in Account settings then IP Restrictions.


How does bitcoin prevent this network splitting attack? How are malicious nodes prevented from, after getting the nonce of a new block found by someone else, broadcast it to the other nodes claiming it to be its?

Also, how does the bitcoin system solve the situation of an evil miner who has found the nonce of a block and then sends it with 2 different nodes, each one reaching 50% of the network, therefore having a problem of ownership of this work?

Finally, if all nodes have to check a broadcasted nonce to prove it's legit, how does the network defend against attacks in which thousands of ip adresses (e.g. botnet) start sending wrong nonces, causing a cpu DDoS because of all the peers hashing and checking these nonces.

Thanks for the answers.

Note: As the three questions are related I thought that putting them all in a single question was correct, if not told me and I will edit the text to only contain the first question, placing the other two in different questions.

How are malicious nodes prevented from, after getting the nonce of a
  new block found by someone else, broadcast it to the other nodes
  claiming it to be its?

The nonce is found against a block which contains the coinbase transaction which claims the reward to the address of the person who found that nonce. So you can't claim it to be yours. You're incentivized to broadcast it to as many peers as possible to help it spread more quickly, but that nonce only works for the block which contains that specific coinbase transaction. Changing the coinbase transaction to claim the coins yourself would result in a different hash of the block and therefore you'd need to find a new nonce.

  Also, how does the bitcoin system solve the situation of an evil miner
  who has found the nonce of a block and then sends it with 2 different
  nodes, each one reaching 50% of the network, therefore having a
  problem of ownership of this work?

Not sure I understand this question but if there's a node with more than 50% of the hashing power of the entire network combined, we're in for larger problems.

  Finally, if all nodes have to check a broadcasted nonce to prove it's
  legit, how does the network defend against attacks in which thousands
  of ip adresses (e.g. botnet) start sending wrong nonces, causing a cpu
  DDoS because of all the peers hashing and checking these nonces.

Again, nonces work with the hash of a block. All you have to do to check the validity of the nonce is see whether the resulting hash is smaller than a specific value. If it is, you've found a valid block! So there's no problem in checking or DDoSing the nonces. In fact that's what mining is: a race for finding a valid nonce for the next block.


Getting IP address of other NXT / Ardor peer nodes for Open API access? I know that peer explorer has an API to access all the IP addresses of NXT / Ardor nodes via: http://www.peerexplorer.com/peerexplorer-api

But say peer explorer is down. How would one get the IP addresses of other NXT / Ardor nodes via a locally installed NXT / Ardor node?

Use the getPeers API and specify the desired service(s).  For example, to retrieve nodes with an open API (either HTTP or HTTPS) from an application, issue the following HTTP request:

https://localhost:7876/nxt?requestType=getPeers&service=API&service=API_SSL

You can use the API test page at http://localhost:7876/test from your browser to view the same information.


Generating a QR code using the NXT / Ardor api for scanning Currently the nxt gui generates a QR code for certain pages where you can scan with your phone or another computer to do an air gap transaction. How can you do this via the api?

https://nxtwiki.org/wiki/The_Nxt_API_Examples#Encode_QR_Code

You can do the following:

http://localhost:7876/nxt?
  requestType=encodeQRCode&
  qrCodeData=NXT-7A48-47JL-T7LD-D5FS3&
  width=100&
  height=100

Or via the command line:

curl -d requestType=encodeQRCode -d qrCodeData=NXT-XXX-XXX-XXX-XXX -d width=100 -d height=100 http://localhost:7876/nxt

You can use it in an image tag like this:

< img src="data:image/gif;base64,R0lGODlhEAAQAMQAAO....." width="100" height="100" />


Addresses are associated with output scripts (scriptPubKeys). This information is not encoded in the transaction, the only information in the input is the txid and index of the output that is being redeemed. In order to do this offline you need to have the previous transaction.

The way they do it for inputs is they look up the previous output that the input is spending in their internal database and get the script from there.

In your example, this is the first input:

    {
        "addresses": [
            "38Rgbmaxitveg1S8UNbWjwV5UMoBt3PtnG"
        ],
        "age": 539082,
        "output_index": 0,
        "output_value": 18640,
        "prev_hash": "f0fa97af6ba86096d9efcfea0bef4d6d146552bdf70e25b067dce1c1520d37b4",
        "script": "2200202dc520822e73d4262000d3b456b16df1d07b0ba9d238f3063379d65840fd38e7",

        "script_type": "pay-to-script-hash",
        "sequence": 4294967294,
        "witness": [
            "",
            "304402202575f8326e510b8213d70a8213ab1a36cd2984b16673ef3579960d0089ad13de022020ec4e78129c084103909acec0319f7d326fff699de142ab354be9570d68dc1701",

            "304402202bc22860e84e0311bbc175940c2b3b5435255dc7ca3fb0d12e5f03df80237b880220536eceee1aace094825f0fd884d057e395102f4e4627188fe6dd5648cdc7a45701",

            "52210274ecb4e28e6b7be314d844bb7561b605d537106f7f5c3eaba31a8cd3dd0097c8210343ed9c58350b4013b3c9a02da2148d59e8109a90f0fa0ea77d31b8570990d46352ae"
        ]
    },

So you have to have the full tx with txid f0fa97af6ba86096d9efcfea0bef4d6d146552bdf70e25b067dce1c1520d37b4 in which case you inspect the first output (index 0) and from this output's script OP_HASH160 49e282ad0605c1cb63ff45fc34b14357859e8d08 OP_EQUAL you can derive the address 38Rgbmaxitveg1S8UNbWjwV5UMoBt3PtnG


How come that there can be many transfers in a single Bitcoin transaction? In Ethereum one transfer has one transaction ID. How come there can be many transfers in a single Bitcoin transaction? For example, in this transaction:
https://blockchain.info/tx/d98491f6697955d9bdb565587a6ae021723a52d5c86a3be04a3f3027329a7175

Ethereum is an account based system. It relies on the sender specifying the sequence of transactions to prevent double spending. The balance is associated with an address and when you spend from that address, you can specify what portion of the balance should be spend.

Bitcoin is not an account based system, but structured around transaction outputs. Double spending is prevented by making each transaction output only spendable once. Thusly, transaction outputs have to be spent in full when used. This has advantages and disadvantages: For example this allows funds to be easily mixed from multiple addresses, even if they are controlled by different parties. Also, transactions don't block each other when one is delayed, other than in the account-based model. However, it's unlikely to have the a matching spendable amount to what you're trying to send.
Bitcoin therefore allows many inputs and outputs, where inputs reference existing unspent transaction outputs that will be consumed and outputs specify who can spend the money next. In practice the count of inputs and outputs is only limited by the transaction size which above 100,000B becomes non-standard.


Is Bech32 transaction on blockchain.info size accurate? I have made a transaction and paid like 120 sat/B, on blockchain it says that I've paid 78.995 sat/B and noticed that transaction size is 191 (bytes)

Transaction size supposed to be: 102 (input) + 32 (output) + 10 (headers) = 144 Byte

Is this a problem of blockchain.info and transaction fee is right or the wallet didn't send the correct fees and Do miners take my transaction as I paid 120 sat/b or 78 sat/b?

87e4a93012116020d7c385d92a0d307363e8040bfb89800c709f66c47ca58316

Your transaction size calculation is incorrect. The inputs are 1 byte input count + 36 byte output + 1 byte scriptSig + 4 byte sequence + 1 byte witness stack count + 1 byte signature length + 71 byte signature + 1 byte pubkey length + 33 byte pubkey = 149 bytes for all of the input data. That along with 32 bytes for output, and 10 bytes for the rest of the transaction gives you a transaction 191 bytes in size.

So, blockchain.info correctly calculated the serialized size of your transaction. However that size is not the one that miners use for computing the feerate of a transaction since segwit data is discounted. Rather what they use is the fee per weight unit, which is the 34.526 sat/WU value that blockchain.info displays beneath the fee per byte feerate.

It's likely that whatever wallet you were using was using virtual bytes (vbytes) instead of weight units or actual bytes. Virtual bytes is just the size of the transaction but applying the segwit discount to the segwit data in the transaction. Your transaction is 110 vbytes, which gives you a feerate of 137.16 satoshis/vbyte. It's possible that when you told your wallet to use a 120 sat/byte feerate, it actually used a 120 sat/vbyte. However, when the transaction was actually made, the change that would have been left over from targeting that feerate would create a dust output, so it was rolled into the fee itself thus increasing the feerate that was actually paid.

  Do miners take my transaction as I paid 120 sat/b or 78 sat/b?

Your transaction has already been confirmed.


If cryptocurrencies have no intrinsic value, how do they originate? In theory, anyone could create an infinite quantity of their own cryptocurrency right now. However, if you were to do this, it would have no value and, thus, it would be useless.

Since value comes from demand, how is it possible to create something from nothing and expect people to pay for it?

You seem to have a misunderstanding:

  anyone could create an infinite quantity of their own cryptocurrency right now

This is not accurate.  The breakthrough that enabled Bitcoin (and other cryptocurrencies) was the ability to make a digital asset scarce without trusting a central authority.

In the past, currencies (digital and otherwise) have required an issuing party, whom we all have to trust won't hyperinflate the currency by creating too much of it.  This might be a regional bank, a central bank, a government, or something of the sort.  Bitcoin changed this.  By using a few clever cryptographic tricks and some game theory, Bitcoin is able to give its users a very strong assurance that hyperinflation will not occur, without anyone trusting a central authority.  Bitcoin has decentralized digital scarcity.

What this means, is that there is a fixed supply (which nobody can reasonably increase) of a currency with a built in transaction network.  There is plenty of demand for such a system, yet limited supply...therefore, there is value.


Sending and receiving address What's the difference between sending and receiving address? I mean, if for mistake I asked to send a payment to my sending address, have I lost my bitcoin? TX

Addresses can both be used both for sending and receiving transactions. However, some online wallet services share addresses between different users, so you want to be careful if you are using one of those. Use a "receive payment function" or "my address", or whatever it might be called, to get the address that can receive payments for you.

If you are using the standard client, all your addresses are fully under your control and are safe to receive transactions.


How does the tx fee in sendmany method get calculated? In sendmany there is a conf_target parameter with the comment "Confirmation target (in blocks)". Does that mean that Bitcoin Core implicitly calculates and sets a smart fee for a given block target?

If so what is the priorities if I:

Set TX fee explicitly before
Set conf_target == 1
Set estimate_mode == UNSET

What will be the resulting fee rate on the transaction in each case?

Does that mean that Bitcoin Core implicitly calculates and sets a smart fee for a given block target?

Yes that's how fee estimation work (basically statistics are made out of the transactions you relay given their feerate and how many blocks it takes for them to be confirmed).

  If so what is the priorities if I:

  Set TX fee explicitly before
  Set conf_target == 1
  Set estimate_mode == UNSET

Assuming you mean calling settxfee by "Set TX fee explicitly before".

The command parameters take precedence over globally-defined parameter, so the conf_target parameter will be used for fee calculation.

Setting estimate_mode to UNSET will make the decision of using conservative estimates depending on either you signal for RBF (use ECONOMICAL) or not (use CONSERVATIVE).


Unconfirmed transaction / double spend warning I transferred some coins from my Electrum Wallet to my Coinbase Wallet, however the transaction got stuck as unconfirmed (possibly because of low fees).  It has been already 19 days since the transaction, the coins are still showing as unconfirmed in Electrum wallet and I can not use them as well.

I am also getting a double-spend warning on BlockCypher.  How can I push this transaction through without losing my coins?

if the fee is not below 0.0001BTC/KB.    you can accelerate the transaction using viabtc accelerator.
https://pool.viabtc.com/tools/txaccelerator/


What would happen to the Bitcoin network if all miners simultaneously stopped their mining efforts? If every single Bitcoin miner were to stop mining altogether, how would this effect the Bitcoin network?

Transactions would never acquire any confirmations and the network would be essentially useless. In principle, people could still accept transactions if there were no conflicting transactions, but anyone could perform a transaction and then undo it if they wished to do so.


Lightning Node Daemon hangs at "Initializing btcd backed fee estimator" I have been trying to connect to my btcd backend on an external server but when I run:

lnd --bitcoin.active \
    --bitcoin.mainnet \
    --debuglevel debug \
    --btcd.rpcuser myuser \
    --btcd.rpcpass mypass \
    --externalip X.X.X.X:xxxx \
    --btcd.rpccert=rpc.cert

I have also tried including --btcd.rpchost=X.X.X.X:xxxx in the command above

I am faced with this output:

2018-07-30 18:04:13.863 [INF] LTND: Version 0.4.2-beta commit=
2018-07-30 18:04:13.863 [INF] LTND: Active chain: Bitcoin (network=mainnet)

Sometimes I would get more output and would be prompted to input the password for my wallet yeilding me an input that looks like this:

2018-07-30 18:31:52.781 [INF] LTND: Version 0.4.2-beta commit=
2018-07-30 18:31:52.781 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2018-07-30 18:31:52.781 [INF] CHDB: Checking for schema update: latest_version=3, db_version=3
2018-07-30 18:31:52.796 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2018-07-30 18:31:52.796 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080
2018-07-30 18:31:52.796 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-07-30 18:31:58.391 [INF] LNWL: Opened wallet
2018-07-30 18:31:58.450 [INF] LTND: Primary chain is set to: bitcoin
2018-07-30 18:31:58.453 [INF] LTND: Initializing btcd backed fee estimator

After around 20 minutes the connection would time out and LND would give me this:

unable to create chain control: dial tcp 127.0.0.1:8334: connect: connection refused

I have verified that the credentials in btcd.conf and btcctl.conf on my external server are the same

My server is definitely running because I can call the btcd server with this command:

btcctl -u myuser -P mypass -s X.X.X.X:xxxx getpeerinfo --rpccert=rpc.cert

Also, btcd isn't giving me any authentication errors when I'm trying to connect to it to LND. It probably doesn't even know my daemon exists.

Does anyone know why I can't connect to my server?

I also run btcd/lnd. First you need to confirm your btcd port is up in address mentioned.

netstat -an | grep port

On the lnd node see if you can connect to the port
telnet xxx.xxx.xxx.xxx xxxx

Change your btcd to debug mode in btcd.conf. You will see in btcd log if lnd is able to reach and what are the errors. Make sure also this is not a firewall issue, you would need to create a rule for that port.


Ripple: How to monitor multiple accounts reliably and effectively? rpc = RippleNetwork(app.config['RIPPLE_SERVER'])
poll = RippleNetwork(app.config['RIPPLE_SERVER'])
last_ledger = Variables.get('ripple_last_ledger')
poll.subscribe(streams=['ledger'])

while True:
    trans = []
    try:
        rst = rpc.account_tx(account=withdraw_wallet, ledger_index_min=last_ledger, limit=1000)
        trans.extend(rst['transactions'])
        while rst.get('marker') is not None:
            rst = rpc.account_tx(account=withdraw_wallet, ledger_index_min=last_ledger, marker=rst['marker'], limit=1000)
            trans.extend(rst['transactions'])

    except RippleException as e:
        if e.resp['error'] == 'lgrIdxsInvalid':
            log.debug('ledger_index_min too new, sleeping for 10s')
            time.sleep(10)
            continue

        raise

    for rec in trans:
        tx = rec['tx']
        log.debug('Got tx %s', tx['hash'])

        if tx['TransactionType'] != 'Payment':
            continue

        if tx['Destination'] != withdraw_wallet:
            continue

        log.info('Queue tx %s', tx['hash'])
        tube.put(str(tx['hash']))

    last_ledger = rst['ledger_index_max'] + 1
    Variables.set('ripple_last_ledger', last_ledger)
    db.session.commit()
    # Wait for next(or several) ledger close here.

Code above is my current implementation, but this method does not scale to thousands of accounts.

Is there any 'best practice'?

I'm not sure a large code paste is the best way to get your example across (I'm unfamiliar with the library/API you're using for example). Assuming it's correct to summarize that you are looping, repeatedly doing account_tx RPC calls with at most a ten second delay; then that's not efficient even for a small number of accounts.

For a small-ish number of accounts, I'd recommend doing something like your loop only on restart to catchup from a last known ledger you've processed. (For example, after restarting your monitoring after an outage or disconnect). Once caught up it's better to use the subscribe RPC with the set of Ripple accounts you're interested in. The server will send you a notification anytime any transaction touches any of the accounts you list. This avoids polling and is far more efficient, especially during periods where the accounts are idle. (I'm only familar with using subscribe over a websocket, and it works very well for this even over days; I don't know what library support for this is like).

Once you go beyond a certain threshold of accounts you are trying to watch, especially if they are very active accounts, it may be easier to use the subscribe RPC to subscribe to all transactions and filter those for just the ones effecting the accounts you're interested in. Also, at that point it may become a good idea to do such queries against your own locally running rippled rather than rely on a public Ripple server.

The point at which it's best to switch from subscribing to a list of accounts versus subscribing to all transactions is unclear to me. For starters, there may be a limit to the number of accounts you can specify in a subscribe call; if so perhaps modify a locally running rippled to remove any such limit and have it do the filtering may be appropriate.


When is the Bitcoin payout for solving a block going to change? When is the Bitcoin payout for solving a block going to change?  What happens when overnight it is half as profitable to process a block?

It halves from 50BTC to 25BTC block reward after 210,000 blocks, which at 6 blocks mined per hour by my calculations works out to be in 358 days, which is around Dec 13th, 2012.

It's likely that the number of active miners will reduce substantially at that point, but within a relatively short time the difficulty should adjust down so that approx 6 blocks per hour are mined again. In the time it takes this to happen, transactions may take somewhat longer to be processed and confirmed.


Creating Base58 public key & private key in Java? How can I create a base58 private key and public key in Java? I'm pretty familiar with Java and I have the bitcoinj-minimal code, but it's not clear to me how I can generate a base58 key pair from the code.

com.google.bitcoin.core.ECKey key = new com.google.bitcoin.core.ECKey(); // keypair
byte[] pub = key.getPublicKey(); // byte array

String prv;
prv = key.getPrivateKeyEncoded(com.google.bitcoin.core.NetworkParameters.prodNet());


Will the payout for mining will always be the same? Will the payout for mining always be 0.00000064 BTC?
Because that is what i just got.

No. The payout is determined by the block reward divided by the difficulty. The block reward halves every 210,000 blocks and the difficulty changes based on the total amount of mining.

As I write this, the block reward is 25 BTC and the difficulty is 37,392,766. Dividing gives .0000000668, which would be the pay per share at this moment for a pool that charged no fees and kept all transaction fees.


In btc network does the limit of Vin should be less than 1000 in for a single transaction? Suppose i am doing transaction which involves more than  50k Vins. I found that i cant do thaat in a single go. So is it true that even if the size of block is less than the maximum limit, i cant do that transaction because of limit in Vins?

Bitcoin Core enforces a standardness limit on the weight of transactions of 400000 (corresponding to 100000 bytes for non-segwit transactions). Note that miners are not required to follow this limit (though most do), and larger transactions are absolutely valid inside blocks.

There is no specific limit on the number of transaction inputs.


What if periodic redistribution of bitcoin had been built in the protocol/wallets? Imagine if there was a Bitcoin-like currency that had periodic wealth redistribution built in the protocol. For example, every month you and every other wallet would pay 20% of their bitcoin evenly to everybody else.

I know the idea has a lot of technical challenges/flaws, but on principle what do you think of the idea? Would it incentivize more transactions and economic activity?

Early miners/users own most of the bitcoin supply and there is not much incentive for normies to get involved because a small number of whales are controlling the network and there is no way to get access to meaningful sums of bitcoin.

It's just an idea -- what do you think?

For example, every month you and every other wallet would pay 20% of their bitcoin evenly to everybody else.

There is a technical issue with this, and a social issue:

Technical: How is it decided where the 20% gets paid to? How do we determine that each actual human being is being paid, and only being paid once? If you agree to centralize the control of this function, it isn't too tough: everyone just registers their identity with the central authority, so that the central authority is solely responsible for ensuring all payments are accurately made.

Of course, this is entirely antithetical to the design of bitcoin: there is no such hierarchy or position of authority in the network. Without the central authority, there is an obvious issue: a single human could just register many different address/devices/IP addresses/etc, to gain more than their 'fair share' of the redistribution**. This is a fundamental problem for decentalized systems, it is not trivial to solve.

Social: It will likely be difficult to convince people to opt into a system wherein they may lose up to 20% of their net worth every month. I think you can set this tax to whatever level and frequency you'd like, but it won't change the situation much.

The function of such a system would depend on the altruistic participation of the wealthy. This is not a stable proposition, we should expect that a wealthy and rational actor may not opt in to such a system, given the choice.

  Would it incentivize more transactions and economic activity?

It would incentivize moving your wealth into a different financial instrument/money.

These two ideas, bitcoin and wealth re-distribution, are inherently incompatible. Bitcoin is entirely opt-in, whereas for wealth redistribution to really work, you need a system which does not allow the users to opt-out.

**Interestingly, bitcoin mining is itself a solution to this problem: users that want to gain the reward must prove that they have spent energy securing the network to do so. There is no way to fake the energy, and spending more energy does not win you a disproportionate amount of the reward. Bitcoin mining is a probabilistic solution to this problem of sybil-attacking the network: the attacker can no longer fake being a large number of nodes on the network, they must spend real resources to participate.


"BitCoin-QT" Core Upgrade - PRIOR Steps? I plan an upgrade of an old "BitCoin-QT" Core client wallet from 'V0.7 2-beta' to the latest Bitcoin Core 0.15 (Oct 2017).

I've got good instruction on the upgrade path - but my questions is:

Besides backing up my ‘wallet.dat’ (in case something goes wrong in the upgrade) - is there anything ELSE I should consider in this big Upgrade leap ? Thanks

bitcoin-qt 0.8 changed the database structure. Bitcoin Core 0.15 changed the database structure again. There is no direct database structure upgrade path from bitcoin-qt 0.7.x to Bitcoin Core 0.15. You will have to upgrade to a version between 0.8 and 0.14 first before you can upgrade to Bitcoin Core 0.15. I recommend first updating to Bitcoin Core 0.14.2, letting it build the databases and sync, then upgrading to Bitcoin Core 0.15.0.1.

See also: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.md#how-to-upgrade


In ECDSA, why is (r,−s mod n) complementary to (r, s)? I am trying to find resources in previous malleability posts, but couldn't find derivations/proofs of this fact or how the exact low-s value is derived. Any pointers would greatly appreciated.

ECDSA signatures are pairs (r,s) such that r = x(m/sG + r/sP) mod n, where P is the public key and m is the message digest. x() in that equation means "the X coordinate of".

In that equation, if you substitute s = -s', you get *r = x(m/(-s')*G + r/(-s)P) mod n, or *r = x(-(m/s'*G + r/s'P)).

However, it is true that for any point Q, x(Q) = x(-Q), as negating a point only affects the Y coordinate. Thus, *r = x(m/s'*G + r/s'P) mod n, or (r,s') is valid signature whenever (r,s) is.


Are balances for an address visible? If you know someones BTC address, can you also find out what their balance is?

Does it also apply for the transaction history for that address?

I'm mainly asking because I want to know if it's possible for me write a script that can do this.

Yes.  All Bitcoin transactions are recorded in the public blockchain, and this gives you sufficient information to compute the balance of any address.

Sites such as blockchain.info and blockexplorer.com will conveniently show you such info, as well as complete transaction history for an address.

http://blockchain.info/address/13PWYdQ1bAFFkzgcfA4avzSp8iaPzUD7CE

http://blockexplorer.com/address/1NVdrDdS52R4Tb8w9tKnTaVk1WxkVSEh6Z


How to index the UTXO set efficiently? I haven't been able to find information on how to efficiently index UTXOs. Can you explain or point me to some resources?

Update: Btw, I understand completely that the notion of address balance is awkward at best, and that it can never really be known with 100% confidence, especially as P2SH transactions gain popularity.

I believe what you are looking for is and address based index for txout. Have a look here https://bitcointalk.org/index.php?topic=1395749.msg14194272#msg14194272

Your basic idea of keeping a map of address -> txout is ok. You might want to rethink about storing in memory. Current bitcoind chainstate is around 1.2G (compressed state).


Bitcoin Cash testnet version of insight API I was wondering if anyone know a testnet version of Insight API for Bitcoin Cash?

For mainnet there are those:

https://bch-insight.bitpay.com/api/
https://bch-bitcore2.trezor.io/api/

But I cannot find one for testnet.

Thank you very much.

With a trial & error procedure I've found this one :-)

Prefix for APIs is https://test-bch-insight.bitpay.com/api

For example:
https://test-bch-insight.bitpay.com/api/addrs/2MzrMhMEPN9KYsZHgijMqekPa8kmvwsuEVm,2N1w811DgtWzjHdwtP1zzbXqJdh9vNK3sk9,2N3rs2KJBYxZQifg5TY6Bjb8CGcvmYTppsG/utxo


What is the difference between mauling and transaction malleability? http://stevengoldfeder.com/papers/ZKCSP.pdf notes:

  The protocol presented in [5] is vulnerable to the so-called mauling problem, where an adversary
  which knows the hash identifier T of a transaction is able to come up with a hash identifier T
  0
  that
  is semantically equivalent to T (i.e. spends the same transaction, has the same value, and the
  same inputs and outputs). As the authors of [5] point out, there are many Bitcoin software clients
  that cannot handle transactions appearing in the ledger with an hash identifier which is different
  from the original one (namely, the one with which they were posted) [3]. This effectively makes
  the transaction unredeemable, causing problems when creating Bitcoin contracts [2,3]. While the
  authors acknowledge the mauling problem, their scheme only addresses mauling due to malleability
  in ECDSA signatures, but does not address mauling due to changing the script.

The reference [5] cited is Efficient Zero-Knowledge Contingent Payments in
Cryptocurrencies Without Scripts

This sounds a lot like transaction malleability. What is the difference?

If it is not the same, is mauling fixed by Segregated Witness?

They define what they mean by mauling in the referenced paper:

  As described in Section 2, the Bitcoin transactions are identified by their hashes, more precisely: TXid(T) = H(T) (where H is the SHA256 hash function). This can sometimes be a problem, since it turns out that often the adversary that knows T can compute T' that is semantically equivalent to T (i.e.: spends the same transaction, has the same value, and the same inputs and outputs), but is syntactically different from T. This is called mauling the transaction T. In a moment we will explain how mauling can be done, but let us first say what are the consequences of this attack. The problem comes from the fact that in such a case TXid(T) != TXid(T'). Note that this does not imply that the adversary can steal money (as the output of T is the same as the output of T'). Still, it is undesirable in many situations.

This is the same thing as transaction malleability.

Would segregated witness solve this? I believe so. If every input is a segwit spend, that solves every kind of transaction malleability, except when the attacker has a copy of every private key that signed the transaction.


No .altcoin directory being generated I am trying to create a genesis block for a personal play coin. I get the correct output of assertion failed. However when compiling I noticed the ./altcoin folder is not created at all.

The data directory (~/.altcoin) is created when the software is run, not when it is being compiled. Compilation has nothing to do with the datadir.


can i solo mine with minepeon? i'm solo mining but it just doesnt feel right that i don't get any accepts while solo mining.

is this right? (see picture below; the top pool with the blacked out adress)

settings:

bfgminer options: -S all -c /opt/minepeon/etc/miner.conf --no-longpoll --coinbase-addr 1NCWZT4hbfPw5LMpPsPauXYdVB9LYKrZM7 --icarus-options 115200:1:1 --icarus-timing 3.0=100

While solo-mining the miner falls back to attempting to create real-difficulty shares, a.k.a. blocks. Hence you won't see a share until you actually find a block. The only reason that pools use lower difficulty shares is in order to determine which miners are actively attempting to mine a block. Since you are the only miner there is no need to keep tabs on the miner, it's already clear who's going to get the reward.

tl;dr: this is perfectly fine, as long as the miner is showing a hashrate you'll find a block eventually, although with your current hashrate it'll take 193 years in expectation for you to find a block.


Can receiving money make a transaction fail? Scenario: Alice has a wallet A1bz (let's say these are the first 4 characters of the private key in wallet import format so we don't have to deal with too many characters) with wallet address 1A1 and 100 mBTC in it. She also has a wallet A2bz with wallet address 1A2 for change and wants to send 50 mBTC to Bob's wallet with public address 1B1 at 15:00 but only pays 0.01 mBTC fees (as opposed to 0.1 mBTC) which would be the recommended amount. This means that the transaction probably won't go through right away but will have to wait for a few hours.

This means that transaction1 is built like this:

transaction1: (1A1) -> (1A2(49.99 mBTC), 1B1(50 mBTC), fee(0.01 mBTC))

So transaction1 requires that there are 100 mBTC in wallet 1A1.

However, Carlos comes along and sends 1 mBTC to Alice at 15:05:

transaction2: (1C1) -> (1A1(1 mBTC), 1C2(4.9 mBTC), fee(0.1 mBTC))

transaction2 goes through right away in the block which closes at 15:10. transaction1 isn't confirmed at that point in time.

Does this mean that Carlos aborted transaction1? Afaik, the inputs need to be depleted entirely which is why change is needed in the first place.

No.

The addresses in Bitcoin only signify ownership. You don't need to spend all money from an address or any such thing. The atomic units of Bitcoin transactions are Unspent Transaction Outputs (UTXO).

UTXO are uniquely identified by the txid of the transaction that created them, and their position in said transation's output list.

E.g. if the transaction id of transaction1 were tx01 the 49.99mBTC output to Alice would be tx01-00 and the 50mBTC output to Bob would be tx01-01 (computer scientists start counting at 0).

To spend a UTXO, you'd reference them by this identifier, i.e. "I want to spend tx01-00". Then you need to provide a signature that corresponds to the address that tx01-00 was assigned to, and you get to reassign the balance that tx01-00 represents. Afterwards, tx01-00 is invalidated.

So, in your example transaction1 spends UTXO that are unrelated to transaction2, so transaction2 has no bearing whatsoever on transaction1.


transaction malleability "attack" vectors are any of the following transaction malleability "attack" vectors currently feasible?

alter scriptsig from:

OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>

to one of:

1) OP_1 OP_SHA1 OP_DROP OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>
2) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_1 OP_SHA1 OP_DROP
3) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_NOP

so that the corresponding scriptpubkey still evaluates to true:

OP_DUP OP_HASH160 OP_PUSHDATA <address> OP_EQUALVERIFY OP_CHECKSIG

i can't tell if this is handled by point 6 in bip 62 or not:

  Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding
  scriptPubKey, is also a source of malleability.

judging by the code it looks like it has been taken care of, but my c++ knowledge is not great...

Point (6) does not eliminate this source of malleability. Rather, point (2) of BIP62 disallows all three modifications you suggested. BIP62 describes the problem:

  Non-push operations in scriptSig Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.

And the proposed solution:

  Non-push operations in scriptSig Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: Push operators.


Where can new cryptocurrency features be found? I was wondering what new cryptocurrency features may be introduced.

How can I find published new cryptocurrency features?

Have a look at the hardfork wishlist for Bitcoin. These are changes that are just to hard too do in Bitcoin as they would require major changes to existing infrastructure, but are generally considered good ideas or at least worth experimenting with.


Transfering btc from blockchain to electrum wallet, still unconfirmed i transferred btc from blockchain to electrum wallet. it has like 132 confirmations but on blockchain it's still Pending: 0/3 Confirmations Status. I paid fee and everything. Is this something normal or Is there anything happening? this is my first post here. thanks much

There is currently a Phishing attack going on with electrum. Did you make sure you downloaded electrum from the official site? Also with wich electrum servers did your electrum wallet connect? Maybe one spreading false information to trick you into their fishing attack


Does coinbase pay for my transfer fees? I'm new on coinbase.com, and it looks like (surprisingly), when I order a 0.1 bitcoin transfer to somebody's address, then if I look at the transaction on blockchain.info

Network fees of 0.224 E-3 BTC are paid

Source address pays 0.1 + fees + change
Another coinbase related address gets the change
recipient gets 0.1

The recipient gets the full 0.1 BTC (they confirmed)
My account goes down of only 0.1 BTC

Who pays the network fees? Coinbase on their own money (sounds very surprising)?

At the time of the question being posted, Coinbase was paying your transfer fees. Starting on March 21st 2017, they stopped paying the transfer fee and the user now pays the fee.
Coinbase has blog post about it here:
https://blog.coinbase.com/coinbase-spring-cleaning-4f27710ff821#.b8hzpa2hb


Tracking the Bitfinex hacked coins How can someone like an exchange track the Bitfinex hacked coins to make sure the hacker cannot exchange them?
Does a service exist to make it easy for the exchange to call an API with the deposit txid and get back an answer if the input coins are tracked to the hack?
Update
I understand that people don't like the idea of tracking bitcoins, but as an exchange if bitcoins associated with the hack are deposited on your platform and allowed to be converted into USD you are potentially liable for facilitating a crime. An exchange needs an easy way to keep track of these coins so at the very least they can put a hold on the user's account while investigating the source of the deposited coins. This happens with USD all the time, so I'm not sure why people would expect bitcoins to be any different. No exchange wants to be a party of criminal actions.
Hopefully now the question is more clear. So does such a service exist or must the exchange write their own code to handle this?

This is possible. It also may sound good on paper, but the implications are horrible.

Think of it. 100 thousand bitcoin. 0.5% of all coins will be rejected. This is out of 21 million. Out of the current 15 million, maybe 0.65%. That's hugel

If a hacker also wanted, he could move the coins into multiple mixers and deposit them in and out of Exchanges, as they're off-chain. Hacker could even sell a couple.


Does a transaction with a lock time need more time to be confirmed? I've made this transaction in the testnet:

https://testnet.blockexplorer.com/tx/2f18c646a2b2ee8ee1f295bb5a0f5cc51c5e820a123a14b0c0e170f9777518bb

It's a multisign tx with locktime. The locktime has expired and the tx is signed, but it isn't confirmed... Does somebody know why this tx isn't confirmed?

Thanks

Mempools are constantly changing. Each node has its own policy (how much of it to keep, when it gets cleared, which ones stay when a block is found, etc) so it's difficult to know if your transaction is on the network. Generally, you can be sure that a tx with a sufficiently high locktime won't be in the blocks before that locktime, but you are not guaranteed that it will be in the blocks after for a lot of other reasons (insufficient fee and mempool turnover being the two big ones). Generally with these types of transactions, it's recommended that you broadcast after the locktime has passed.


Are Bech32 addresses safe for mainnet usage? According to github bitcoin/bips, BIP-173 is still a draft. And i saw today that Electrum wallet start using it.

Is this means that the specs for BIP-173 won't change in the future ? or the final version won't introduce breaking changes to the draft version ?

I just learned about Bech32 addresses this week and this gets me a little confused

Yes, they are. Bech32 addresses allow for native Segwit outputs, which offer higher efficiency and security than the legacy P2SH nested Segwit outputs. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations has reference implementations in C, C++, JS, Go, Python, Haskell, Ruby, and Rust along with tests courteous of Pieter Wuille


How to migrate bitcoin node from one computer to another In my old computer some addresses have bitcoin and it is showing on blockchain.

When i am trying to get balance of the same addresses in my new computer where i have synced bitcoin full node ,I surprised addresses showing zero balance.

I am very confused, how can i backup bitcoin wallet from old computer to another

This method is used by Bitcoin Core (and few others) and comprises of backing up a wallet.dat file. It's a file that holds keys to spend outputs, addresses, transaction information, and other metadata such as contacts.

It has a different location based on an operating system.

  Windows: %APPDATA%\Bitcoin
   Linux: ~/.bitcoin/

  Mac OS X: ~/Library/Application Support/Bitcoin/

For backup Locate wallet.dat and copy it to another device only you have an access to. It may be a USB drive, CD, another computer or your private home cloud storage.

You may also copy it to a cloud storage such as Mega or Dropbox but make sure it's encrypted.

To restore the backup, simply copy your backed up wallet.dat over an existing one in the bitcoin data location.


What would be the consequences to lower the difficulty such that a block is generated every 5 minutes? The difficulty is adjusted such that a block is generated every 10 minutes.

What would be the consequences to lower the difficulty such that a block is generated every 5 minutes?

The most important consequence:

It would increase the orphan rate, which gives big miners more chance to mine (because they run their own ISP, while a miner with 0.1% hashrate of the network probably doesn't), and this leads to centralization.


What going to happend with transactions that is in both rejectend AND accepted chains? I have been reading about blockchain forks and the longest chain situations and I cannot really understand what is going to happend in the situation when the transacton were included in both accepted AND rejected blocks?
If transactions in rejected block are going back to the mempool, does it means that there will be blocks with duplicated transactions?
I have drawed something out for better understanding of this:
https://imgur.com/a/3ViIu
I guess I`m missing something fundamental here.
Thanks in advance!

Tx message Rule# 8: https://en.bitcoin.it/wiki/Protocol_rules
Reject if we already have matching tx in the pool, or in a block in the main branch.


Are there any existing tools to measure the time required for block and transaction validation？ The validation time of transactions and blocks has a great impact on the performance of the Bitcoin network. Are there any special measuring tools that can be used?

Bitcoin Core has inbuilt benchmarks which can be enabled using debug=bench, which breaks down the validation time of incoming blocks.


What determines how many transactions end up in a given block? What determines how many transactions end up in a given block? Blocks can have various numbers of transactions, so what decides how many are in a certain block?

Miners (that is, the full node building the miner's blocks - which may be a pool) decide what they put in blocks.

Reasons for including more transactions:

Earn the fees of transactions included.
Make the Bitcoin on-chain ecosystem more useful.

Reasons against including more transactions:

Larger blocks propagate more slowly through the network, giving them a slightly larger chance for being reorganized (as a competing simultaneous block may win).


Do bitcoin miners calculate the hash value of current block or next block? I'm new in bitcoin and my question seems be stupid. I appreciate your help.
Miners calculates blockhash as picking a proper nonce.
And he is awarded.
To calculate block hash, he will need 6 values. 2 of them are merklehash and nonce.
I'm gonna say about merklehash and blockhash. Suppose that miner A is trying to calculate.
To calculate blockhash, merklehash is needed. But merklehash is a hash of all transactions of the block. The first transaction data is that a miner is awarded(?). That means merklehash is calculated after awarded miner is determined. What's the difference between awarded miner of this block transactions and A? I really don't understand.

After reading your question, you are a little confused, so i will try to explain:
Miners do double round of SHA256
What they hash?
They hash the blockheader...
What's the blockheader?
The blockheader is build from data
What data?
It's Build from:
Version: The version of the block.
Previous block hash: The Block Hash of the block that this block is being built on top of. This is what “chains” the blocks together.
Merkle root: All of the transactions in this block, hashed together. Basically provides a single-line summary of all the transactions in this block.
Time: When a miner is trying to mine this block, the Unix time at which this block header is being hashed is noted within the block header itself.
Bits: A shortened version of the Target.
Nonce: The field that miners change in order to try and get a hash of the block header (a Block Hash) that is below the Target.
All this is in little endian


Best way to obtain/earn bitcoins I would like to know what bitcoin enthusiasts and experts would suggest me for earning or mining my first BTC. I own some BTC but the idea of mining is a lot more exciting.

I read some articles but it seems to me that I have already missed the big "boom" of mining year or two ago, when you could mine with GPU or even CPU. Some people say, that investing into ASIC miner is a non-sense because it takes a long time to deliver and during this time the difficulty of network increases and when the ASIC miner finally arrives, you are satisfied when you don't loose money at the end.

So my question is how do you mine? What is the best way to earn few bitcoins and don't loose money?

This is quiet exciting article that I read months ago, which turned out in great ROI.

EDIT: I would like to know, if it is good time to start mining for someone who haven't done that yet.

Mining was never supposed to be profitable. And it's a derivative of bitcoin which is already risky speculation.

Don't add the extra, annoying risk-without-an-upside of wondering whether BFL will ship your machine in time to turn a profit. Even they state that there's no guarantee that their machines are profitable.

If you are sure that the price of bitcoin will go up, or even if you're not sure and you just want to take a bigger risk with more money, just buy more bitcoin.


Converting NodeID and BitcoinKey from Lightning Network (LND) logs From the LND logs I have something like this (I changed some characters for privacy):

NodeID1: ([33]uint8) (len=33 cap=33) {
 00000000  02 19 8b 61 42 18 89 24  74 fc 95 ed 64 c4 77 91  |.9.a@(.$t...d...|
 00000010  e9 94 97 50 42 d0 bd 7e  95 91 b0 ec 41 28 ab ac  |...PB..~....A(..|
 00000020  e4                                                |.|
}

BitcoinKey1: ([33]uint8) (len=33 cap=33) {
 00000000  02 63 a4 ca a4 63 8c 3c  43 fc 65 8a e5 7c b5 f8  |.c...c.<C.e..|..|
 00000010  a7 8f f5 a4 d8 2e ad 0a  83 3a 17 e1 e8 1e c8 c8  |.........J......|
 00000020  91                                                |.|
}

I read and checked some docs and services, but the result is wrong.

What are the steps to obtain the node pubkey and the Bitcoin address?

I fear that similar questions have been already answered, but I'm still not able to answer mine.

The values you've pasted are the node public key and the funding transaction output public key. The keys are encoded in compressed form (0x02 | 0x03 followed by the 32-byte x-coordinate of a point on the curve). The first byte indicates whether the y-coordinate is positive (0x02) or negative (x03). The 33-byte public key is the format used throughout the BOLT specs. All values in the BOLTs are encoded in network endian byte order.

There is no "bitcoin address" in either of these, nor are any convertible directly to an address. In bitcoin, the funding transactions use a P2WSH output, but the redeem script for this transaction is not revealed until the transaction is spent (channel closed). The only way to reconstruct the redeem script is if you know both funding public keys for the channel. in which case the redeem script is simply 02 <pubkey1> <pubkey2> 02 OP_CHECKMULTISIG, where <pubkey1> is the lesser of the two public keys.

The way Lightning channels are mapped to a bitcoin transaction is through their short_channel_id, which is a triplet of <block_height>x<tx_index>x<output_index>, encoded as a 64-bit integer. (block_height and tx_index as 24-bits each and output_index as 16-bits).

The full channel_id can also be used to map the channel to a bitcoin transaction, as the channel_id is the txid xor output_index.


Where the P2SH script gets written? I understand that when I'm doing a transaction, I'm locking those bitcoins to whoever provide the solution to a script that has the hash I posted.

But, where does the hash get written?

I would assume that it is not in the blockchain, since this payment system is done so we can save space. I can imagine that the nodes store a database of hashes of scripts previously written on the blockchain, so when they see a script hash, they can find the correct script for it. Another option was that the recipient would provide the script at the time of the transaction, but then the other nodes would not be able to verify the script's end result, because the script would not be on the blockchain.

The script is maintained by the intended recipient; he is the one responsible to keep it and not to lose it. The nodes do not store any database of the scripts.

The script is provided by the spender upon spending the p2sh as part of the scriptSig data. For the exact specification of how this data is structured, see BIP 16 by Gavin Andresen. This allows the other nodes to validate that the script was redeemed correctly.

The purpose of p2sh is not to limit the data on the blockchain – that remains the same. It is, as per the BIP, to "move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer".


Does BIP44 key derivation path protects private keys derived within same account? I understand that with

Un-hardened parent extended public key
child private key

This will leads to compromise of parent private key and so all the private keys of siblings

BIP44 suggests the path

m / purpose' / coin_type' / account' / change / address_index

Let's say I use the path m/44'/0'/0'/0 to derive  public keys for account 0

Since The change and address_index is not hardened. And in my application I will have the extended public key at level m/44'/0'/0'/0 revealed (to derive addresses), does it means that if any of the private keys derived at the address_index level is compromised, all the private keys within the same account may also be compromised?

So with this path only avoid further compromise up to

Other accounts and
Further up to the master key?

Am I correct?

Bip44 doesn't protect anything, if the user has master root key, they could get access to all the other accounts private keys.

Your path is wrong, it should be like that:

m / purpose' / coin_type' / account' / change / address_index

What you should do is generating child master private key for the following path:

m/44'/0'/1'/

Now the user has access only to account number "1" and should generate addresses using that child master private key and the following path:

m/changeAddress/addressIndex


JSON-RPC signrawtransaction returns false when using private keys I've been working with BitcoinLib testing various parameters on the signrawtransaction rpc call.

It's been mostly successful, however there seems to be a persisting problem when using only private keys to sign a transaction. (second optional argument of signrawtransaction call). The server replies false and returns the failed hex. I have tested the same transaction on the qt console using the same keys, and it returns true.

The wrapper employs a SignRawTransactionRequest class matching the four arguments of the rpc call.

public SignRawTransactionRequest(String rawTransactionHex)
    {
        RawTransactionHex = rawTransactionHex;
        Inputs = new List<SignRawTransactionInput>();
        PrivateKeys = new List<String>();
        SigHashType = SignRawTransaction.SigHashType.All;
    }

It allows for 'inputs' and 'privatekeys' to be null, following the signrawtransaction syntax, while assuming 'sighashtype=all' unless explicitly specified otherwise.

The implementation also includes a SignRawTransactionInput class corresponding to the first optional argument of the rpc call. ([{"txid":txid,"vout":n, "scriptPubKey":hex, "redeemScript":hex } ,...])

public class SignRawTransactionInput
{
    [JsonProperty(PropertyName = "txid", Order = 0)]
    public String TransactionId { get; set; }

    [JsonProperty(PropertyName = "vout", Order = 1)]
    public Int32 Output { get; set; }

    [JsonProperty(PropertyName = "scriptPubKey", Order = 2)]
    public String ScriptPubKey { get; set; }

    [JsonProperty(PropertyName = "redeemScript", Order = 3)]
    public String RedeemScript { get; set; }
}

The request if fed to the wrapper method RpcServer.SignRawTransaction and returns a SignRawTransactionResponse containing the result and the hex as returned by the server.

public class SignRawTransactionResponse
    {
        public String Hex { get; set; }
        public Boolean Complete { get; set; }
    }

So far, signings using just the hex (no other arguments), inputs, different sighashtypes and various combinations of those have been successful. The server replies TRUE and returns the hex of the signed transaction when called with plain hex

or when called with some arguments

However, it returns false when the second optional argument(list of private keys) is used. It has been tested with one, all, and various combinations of the available private keys of the wallet.

I suspect it might be a JSON error and that the wrapper is not constructing that part of the JSON properly, however that usually leads to a parsing error and not the false reply I get here.

The same combinations return true when signrawtransaction is called from the console.

Any ideas on what might be wrong with the private keys argument?

This was not a case of BitcoinLib malfunctioning in any way. It was simply a case of using wrong privkeys to sign the unspent outputs.


Can a blockchain transaction history be updated by text messages using a mobile network? Is it possible to update Bitcoin transactions over mobile networks using texts or voice data transmission?

No, at present this is not possible. The Bitcoin network runs only over the internet. (Of course, there are lots of mobile data networks in the world, and Bitcoin works just fine over those.)

One could imagine some kind of service to receive transactions by phone or text and relay them to the Bitcoin network (and perhaps vice versa), but I don't think such a service currently exists.  I'm not sure that very many people would find it useful.

What applications do you have in mind for such a feature?


Lightning Network state deprecation secret keeping When using a lightning channel, two sides are sending transactions representing the current state (or balance) between them, and for each state sent, they invalidate the previous state by sending a secret for a hash puzzle in a HTLC transaction.
For example, when Alice sends Bob the new state between them, it also sends a secret for the puzzle in the previous state. Bob can use it to redeem Bitcoin if Alice publishes the previous state transaction on the blockchain.
My question is - does Bob need to save all the secrets of all the previous states until the channel is settled and closed? Sounds like Bob might need to save a lot of data when having many channels.

Unless bob uses a watchtower service where he outsources the storage of data Bob needs to know all previous revocation secrets. However he does not need to store and save all of them as the revocation secretes are derived in a deterministic way. This means whenever I know a revocation secret of a current state I will be able to derive all previous revocation secrets from it.
You can find the details of the key derivation in the key's section of BOLT 03
That being said revocation secrets are not the same as preimages of HTLCs (which I believe your question implies / confuses) The old preimages of settled HTLCs do never need to be stored or need to be reproduced. This is because in the penality transaction case from the second stage HTLCs the revocation secret is sufficient to access the funds before the timelock.


Checks to Verify money sent to any address in a transaction I'm using wallet-less bitcoin daemon (it just syncs blockchain) – the purpose is to read blocks and transactions in them, and do some useful things. This particular question is focused on determining the checks to be made to verify the amount received by each address in a given transaction.

Given tx, I call decoderawtransaction(getrawtransaction(tx)) and receive following details (json):

{
"txid" : "691cb3d61192c7325f203fe14d3d5cf6e98e6bd81877b166f6c37fd629aaa4fb",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "0c0b442e866f007a0da8a2c1abbe8afad8e96217105b561b097aa835b73a6b70",
        "vout" : 0,
        "scriptSig" : {
            "asm" : "3045022100eb01c02b4655c96b08544908bd44d1fbc165971bdc25705ba1b4790c60716dfa022024adeb306f66a72a2a90455035940b89e7c96c8300b6f73f3ae83af605b9c35d01 03ca8ff2ad5114e703d07b3cee962d54609c1de95fd4511e53de91ba0ce35ef4ee",
            "hex" : "483045022100eb01c02b4655c96b08544908bd44d1fbc165971bdc25705ba1b4790c60716dfa022024adeb306f66a72a2a90455035940b89e7c96c8300b6f73f3ae83af605b9c35d012103ca8ff2ad5114e703d07b3cee962d54609c1de95fd4511e53de91ba0ce35ef4ee"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.01000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 8bab392bcc5cfce30affc16336cdd68e807147a2 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a9148bab392bcc5cfce30affc16336cdd68e807147a288ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "mtFTLXKfDxHuJT36cHugYTZw5CVLejqccq"
            ]
        }
    },
    {
        "value" : 0.04000000,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 d86064ea608dd1ceeae690e548979b854ca55360 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a914d86064ea608dd1ceeae690e548979b854ca5536088ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "n1F3j5MdfSLSgpUnaQXNVJb8KBMvnfBYPr"
            ]
        }
    }
]
}

I can see each txout record gives amount as a value (scalar) and addresses as an array.

If addresses array has multiple values, it is a contract (m-to-n transaction perhaps) and I should not consider the money to have been received by any of the  addresses for immediate spend.
Assuming addresses has only one value, what are other checks I must make to verify that the address has received the amount mentioned in the field 'value'?

So I need to know a set of all checks to verify the transaction is confirmed, valid and that a particular address in a particular txout has received the specified amount. confirmation can be ascertained depending on the number of blocks that precede block of this transaction (getblockcount - blockheight).

Thanks!

So you're asking for 3 things: confirmed, valid and that a particular address in a particular txout has received the specified amount.

Confirmed: You've already worked this out.  If getblockcount - blockheight > 0 then the tx has at least 1 confirmation, and so on.

Valid:  Tx are confirmed in two ways:

by validating nodes (full Bitcoin nodes like bitcoin-qt).  Each time a tx is broadcast across full peers, it is validated.
by the network.  This network validation occurs when the network agrees that the block containing the tx is valid, which occurs first time at 1 confirmation and increases in confidence with each additional confirmation.  Being included in a mined block also means that (1) above has occurred at least once (probably much more).

So if you're only considering confirmed Bitcoin transactions, they've already been fully validated by the network and its nodes, so you don't have to do this yourself.  This does not necessarily apply to unconfirmed transactions.

Particular address has received specified amount:  There are rules of thumb here, but to be absolutely sure about this last item, you have to consider the tx script.  Fortunately, all this entails for most transactions is checking for OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG.

This is the relevant part (for you) of the script contained in the scriptPubKey.  As long as it contains this text, you can be sure it's a simple payment in the amount specified to the address specified, regardless of whether it is change or whatever.

If the scriptPubKey contains something else, then you'll need to actually parse the script to figure out the tx details.  How to do this is beyond the scope of this question.

So in brief, to fulfill all your conditions, you need to wait for 1 confirmation and check for the exact scriptPubKey text shown above, or else be prepared t ofully parse the script in the case of a complex contract.


WARNING: abnormally high number of blocks generated I have this error from 5 days ago on my 2 servers

  WARNING: abnormally high number of blocks generated, 48 blocks
  received in the last 4 hours (24 expected)

What is this error ? I need to reindex the chain ?

Thanks you

Luke-Jr commented on this error here: https://www.reddit.com/r/Bitcoin/comments/3ydwg2/warning_abnormally_high_number_of_blocks/#oo

  What this means:

  48 blocks were found within the last 4 hours. The average is
  "supposed" to be 1 block every 10 minutes, or 24 blocks over a 4 hour
  window. Normally, however, blocks are found at random intervals, and
  quite often faster than every 10 minutes due to miners continually
  upgrading or expanding their hardware. In this case, the average has
  reached as low as 5 minutes per block, which triggers the warning.

  If the network hashrate was not increasing, this event should occur
  only once every 50 years. To happen on average, persistently, the
  network would need to double its hashrate within 1 week, and even then
  the warning would only last part of that 1 week. So this is a pretty
  strange thing to happen when Bitcoin is only 6 years old - but not
  impossible either.

  Update: During the 4 hours after this posting, block average seems to have been normal, so I am thinking it is probably just an anomaly.
  (Of course, I can't prove there isn't a new miner that has just gone
  dark or mining a forked chain either, so continue to monitor and make
  your own decisions as to risk.)

  Why is this a warning?

  It's possible that a new mining chip has just been put online that can
  hash much faster than the rest of the network, and that miner is now
  near-doubling the network hashrate or worse. They could have over 51%,
  and might be performing an attack we can't know about yet. So you may
  wish to wait for more blocks than usual before considering high-value
  transactions confirmed, but unless this short block average continues
  on for another few hours, this risk seems unlikely IMO.

  Has the blockchain forked?

  No, this warning does not indicate that.

  Will the warning go away on its own?

  Bitcoin Core will continue re-issuing the warning every day until the
  condition (>=2x more blocks) ceases. When it stops issuing the
  warning, however, the message will remain in the status bar (or RPC
  "errors") until the node is restarted.

Edit: Note that although the gist of the explanation above seems to be correct, the exact number of "once every 50 years" seems to be incorrect (bug in bitcoind code) and is probably more like once every 4 years. Details are in the replies to the above Reddit post.