What happens to extinct blockchains, and transactions inside of them? While understanding the concept of block chain and proof of work, few things are confusing me. Miners always consider the longest chain(by difficulty) and work on expanding it. Now, lets say two miners (Miner A and Miner B) come up with the solution at the same time (almost same time) for a block, and they publicly announces their solution. Then, some miners get first the solution of A , later they see B has the solution as well (just opposite happens to some other miners, they get B first). So, the miners who saw A first starts working over A's solution for next block and saves other branch of B if it becomes longer. Now , tie will be broken when next proof of work found, and miners were working on other branch will switch to the longer one. Now, I have few questions:

What will happen to transaction records which were stored in the rejected branch?
Will there be any transaction records at all for both block branches?
(then I suppose, new transaction records will be stored on last
block before the branch).
What will be the scenario of coinbase generation? if A wins, A gets the coinbase, later transactions
should be stored in A's generated block. But, already solution of
next block(Proof of Work) on the branch A is found. So, new
transactions will be stored on next block (lets say generated by
C..C gets the next coinbase). Is that means, there will be only one
transaction record (coinbase) in the block generated by A?

This process, generally know as forking, creates two parallel chains that are incompatible, that is, there will be some transactions that will be valid against one chain but are not valid against the other.

If there are parallel branches, a miner might keep track of both of them. Once a chain is rejected, transactions in that chain are checked against the accepted one. Incompatible or duplicate transactions are simply discarded, while the remaining can be held over to go in the next block (or blocks as there might be too many transactions for just one).
Transaction records will remain in-tact for the accepted chain, but records for the rejected chain will be merged in to the old branch as described above. It would be impossible to attach these transactions to the final block before the branch, so, they are kept around by miners and put into the block chain as normal.
There might be a bit of confusion here... once a block is mined, it can't be changed, so it's impossible to store further transactions in that block. Furthermore, this block will have exactly one coin-base transaction. Any transactions that happen after it is mined will each be stored in subsequent blocks that follow it, but each of these blocks will have exactly one coin-base transaction, as is specified by the bitcoin protocol. So yes, there will only be one coinbase transaction in the block generated by A.


What does the curve used in Bitcoin, secp256k1, look like? I'm reading up on ECC curves and on many of them I see an illustration that looks like this

What does the comparable curve in Bitcoin look like, or are all curves generally the same?

I'm afraid you won't like the answer.

These curves - including the secp256k1 curve, y2 = x3 + 7` - 'look' nice when evaluated in typical number fields (integers, reals, ...), but secp256k1 is defined over the field Z2256-232-977, which means the X and Y coordinates are 256-bit integers modulo a large number. Curves using such coordinates do not have nice continuity properties.

I've tried to plot this curve over a similar but much smaller field, Z28+1. Coordinates extend from -128 to 128.

Note that even though it may not make sense geometrically anymore, it still has all properties you need. A line (which means, a group of points with equation ay + bx + c = 0) that 'intersects' 2 points of the curve, will intersect a third. Tangent again has no geometric interpretation anymore, but you can still compute a local linear approximation for the curve equation in a given point, which will have the property of intersecting the curve in a second point.

To show you what you'd get if this were over the real numbers, here is a plot of the same curve equation for that case. Once with coordinates -128 through 128, once with -8 through 8.


ELI5: does the number of 0's required in mining for SHA256 over the years strictly increase, or does it depend on how many miners there are? It is said that to discover a block, the person has to get a SHA256 number that has all 0's for the first 72 bits.
Does this number 72 change and become bigger and bigger over the years (say, every 4 years)?  Or does it depend on how many miners are competing?
So that's could mean, in the year 2010, the number of 0's could be the same as in 2020, if there were as many miners in 2010 as today in 2021.

Leading zeroes
The number you refer to is usually called the mining difficulty or target.
The aim of miners is to produce a block with a hash less than that target.
If you represent numbers in binary, a number with more leading zeroes is a smaller number.
For example 00010 (2) is smaller than 00101 (5)
However you shouldn't think about leading zeroes because 00101 (5) is smaller than 00110 (6) but bigger than 00100 (4) although all have the same number of leading zeroes.
It is an arithmetic relationship that is tested, not the number of leading zeroes.
Target value and mining
The target is adjusted up and down regularly. It doesn't continually increase.
The target is adjusted to make the average time to find a new block close to 10 minutes.
This means as there are more miners the target is likely to increase. But more importantly, if there were fewer miners but each had more powerful hardware, the target would also increase, not decrease. It is the total amount of mining power, not the number of miners, that affects the target.
In the past, when the value of bitcoin fell, the value of the mining reward also fell. This can result in less efficient miners leaving the mining business and the difficulty target dropping not rising.

Miners assemble a block of transactions selected from a pool, then calculate the hash, if too big, they make a small change to the block, like change the nonce value, and recalculate the hash, they repeat this until either they find an arrangement that hashes to a value smaller than the target or until some other miner beats them and they have to start all over again.


Error unlocking bitcoin core wallet with JSON RPC I can't get bitcoin core wallet to accept my wallet passphrase so I can get my private key out. The password is correct, as I have tried it to send out and it accepts it, but when I try on the debug it will not. Is it because of the way i write it in e.g. walletpassphase(........)600 or is it
<...........>600 or is it some other way? Please help. It has come up with -32601 and parsing JSON and syntax.

You should write exactly

walletpassphrase "yourPassword" howmanysecondswillthewalletstayunlocked

For example

walletpassphrase "password33482" 6000

Then your wallet will stay unlocked for 6000 seconds.

(You can drop the quotes if your password doesn't have spaces, but it's always a great habit to use quotes.)


How do Reusable Payment Codes work? I've recently heard about "Reusable Payment Codes" (BIP 47), and it sounds like a great feature, except that I couldn't find a simple explanation of how they work.

Can anybody explain them please?

The gist of the reusable payment code BIP is that you can gain some measure of address privacy by combining BIP32 (hierarchical deterministic wallets) with Diffie-Hellman key exchange. To understand what this means, let's figure out what the current situation of bitcoin wallets is.

Originally, in the reference client, bitcoin wallets simply generated random numbers for private keys, which in turn created a bunch of random addresses. This worked great for sending and receiving, but for privacy, it's not so great. If you publish your address, for example, everyone knows exactly how much you're receiving to that address since the blockchain is a public ledger.

Next came along Deterministic Wallets from Armory. This allowed a single seed to generate a virtually infinite number of addresses. That is, you can generate a single wallet from 256 bits (or less) and get as many addresses as you need. This allowed people to send Armory watch-only wallets to each other and get paid that way. Much better for privacy since you're generally only supposed to use new addresses, but once someone is in possession of your watch-only wallet, they know all the transactions in and out of that wallet. Better than it being public, of course, but still something to be desired when it comes to financial privacy, if, say, your employer was paying you via an Armory watch-only wallet, they know exactly how much of that has been moved and so on.

Then came HD wallets (hierarchical deterministic wallets) which allow you to have multiple levels of wallets from a single seed. Now you can send one person one watch-only wallet (xpub in BIP32 parlance) and another person another watch-only wallet and they won't know anything about what the other one is doing. Again, better for privacy, but now you have to give out different watch-only wallets to everyone you're dealing with, which can get messy.

Reusable Payment Codes is essentially a single code (essentially an xpub from BIP32) that you can publish that creates a new wallet when combined with any other HD wallet. This works via Diffie-Hellman key exchange where the sender uses the xprv from their HD Wallet and combine that with the receiver's xpub to come up with essentially a wallet that only the receiver can open but both the sender and receiver can determine the addresses of. As part of the key exchange, the sender has to send the receiver their xpub so the payments can be bi-directional. If you need a refund, for instance, the Payment Code is symmetric so a wallet going the other way can be deterministically be known to both sides. A refund can be sent to the payment code without crazy work-arounds that typify the current bitcoin landscape.

Reusable Payment Codes are essentially a way to identify yourself without leaking any information about how much was received by or sent to that payment code. Addresses, deterministic wallets and HD wallets all do not have this ability.


Multisig and Bitlicense???? Can a business even be a custodian? Lets say a company like BitGo controls one key in a P2SH multisignature address, are they a custodian and subject to the bitlicense?

For enforcement, is it even possible to tell if someone is being a custodian if they use bitlicense?

Any insight appreciated

This falls into an explicitly gray area, as called out by a number of people when bitlicense was first adopted. For example, see; https://twitter.com/twobitidiot/status/606157758224834561 and the linked tweet. Also see: https://coincenter.org/2015/02/our-initial-thoughts-on-new-yorks-revised-bitlicense-proposal/

Practically, if you're not acting as a custodian, then it's unlikely to be enforceable, and they will leaver you alone. If you are, effectively acting as a custodian over the funds, it is possible that NY could choose to go after you - and they have expensive lawyers.


Can miners insert transactions into the block from wallets they do not own? Since Bitcoin blockchain is shared, everyone knows the balance of each Bitcoin wallet. Is it possible for a miner who hashed a block to insert transactions that transfer funds from a wallet to another wallet, without authorization? Of course, given the original wallet has enough funds.

If not, what's the authorization mechanism?

Of course, otherwise you wouldn't see blocks containing transactions at all. Miners are not the only transactors on the network. Miners can include any valid transaction that they wish.

If you are asking whether miners can make a transaction for a wallet they do not control, then no, they cannot. Miners are still must follow the consensus rules, which means that they cannot just make arbitrary transactions for wallets which they do not control. In order to spend from an address, you must have the private key associated with that address. Miners only have the private keys for their own addresses and no one else's so they cannot make transactions for any arbitrary address.


What does a double spend look like? What does a double spend look like? Can anyone link to an example on blockchain.info?

Will invalid half of the double spend simply remain at 0-confirmations, or might it ever reach 1 or 2? Will the standard bitcoind client provide any type of flag for known invalid transactions?

You won't be able to see a double-spend in the block chain, because it is invalid. You will see one of the transactions included in the chain though. Blockchain.info has a page showing the most recent double-spends.

Double spend is just two (or more) transactions claiming the same input, so they will look like an ordinary pair of transaction. One of them will get included in a block, the other will eventually be forgotten by the network. A conflicting transaction to the one included in a valid block can never become a part of another block (at least until the first block will become invalidated by a 51% attack).

The standard client will not flag any invalid transactions, but it will reject any transaction that conflicts with a known transaction. It will, however, accept a transaction that is a part of a block, even if it conflicts with a 0-confirmation transaction that you know of.


RPC call to get unconfirmed balance on a watch only wallet We have a bitcoin core client running on a production machine. This machine cannot have the private key so each address is added as watch only.

So far it has worked perfectly, but recently we need to display the btc amount that is waiting confirmation and the amount that is confirmed (at least 1 confirmation)

bitcoin-rpc getbalance * 0 true
bitcoin-rpc getunconfirmedbalance

these are the two methods that I've found online that should work, but they are not working.

getbalance returns only the confirmed amount and getunconfirmedbalance returns always 0

How can I get the unconfirmed balance on a watch only wallet?

You can use the getbalances command. It will return all of the balances belonging to the wallet, including ones the wallet can sign for, watch only things, trusted (confirmed transactions and unconfirmed change), and immature coinbase outputs.

Here is the help output for it.

getbalances
Returns an object with all balances in BTC.

Result:
{
    "mine": {                        (object) balances from outputs that the wallet can sign
      "trusted": xxx                 (numeric) trusted balance (outputs created by the wallet or confirmed outputs)
      "untrusted_pending": xxx       (numeric) untrusted pending balance (outputs created by others that are in the mempool)
      "immature": xxx                (numeric) balance from immature coinbase outputs
      "used": xxx                    (numeric) (only present if avoid_reuse is set) balance from coins sent to addresses that were previously spent from (potentially privacy violating)
    },
    "watchonly": {                   (object) watchonly balances (not present if wallet does not watch anything)
      "trusted": xxx                 (numeric) trusted balance (outputs created by the wallet or confirmed outputs)
      "untrusted_pending": xxx       (numeric) untrusted pending balance (outputs created by others that are in the mempool)
      "immature": xxx                (numeric) balance from immature coinbase outputs
    },
}


"wallet corrupt salvage failed" Error. Help with pywallet I have an old wallet from 2013 with some BTC in it possibly. I have guesses for what the passphrase could be but not 100% sure on it. Everything I find online is to use pywallet but I unfortunately am a total scrub when it comes to python scripts. So really I am confused exactly what I need to do to obtain the btc out of this wallet. Do I need to extract the private keys from my corrupted wallet and import them into a new wallet? or can I simply merge the corrupted wallet with a new one and the merged wallet will read right? I know pywallet can do all these functions but have no idea myself on how to go about it. Thanks for any help.

Install Bitcoin Core and they can do all this work to import your old wallet.

Bitcoin Core's -salvagewallet try to recover a broken wallet database (wallet.dat file).


How do I find out where a bitcoin address is from? I am not looking necessarily a name but more like is it an offline, coinbase, blockchain.com, etc...

I had $80 sent from my account yesterday and it says it went to 1H8KZWdTeRuiCq4NyCTYGA8Uw9XjKuLPCx however I don't remember this or know this address. I know that this doesn't sound like a lot of money but for me it is. Please help me if you can

How do I find out where a bitcoin address is from?

You can't find a person, organisation or place from a Bitcoin address alone.

A Bitcoin address isn't really an address in the normal sense. It doesn't label a place or person or anything else in the real world. Really its just a reference number produced from a secret number by a mathematical function. You can't even reverse the maths to find the secret number from the address.


How to run my own Ripple RPC server (full node)? I'm following this manual: https://ripple.com/build/rippled-setup/#installation-on-ubuntu-with-alien and getting error below.

ix@pwrg:/media/ix/ledgers/.src$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
Retrieving https://mirrors.ripple.com/ripple-repo-el7.rpm
Preparing...                          ################################# [100%]
    package ripple-repo-1-2.el7.centos.noarch is already installed
ix@pwrg:/media/ix/ledgers/.src$ yumdownloader --enablerepo=ripple-stable --releasever=el7 rippled
rippled-0.70.2-1.fc25.x86_64.rpm                         | 8.5 MB     00:01
ix@pwrg:/media/ix/ledgers/.src$ https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release && rpm -K rippled*.rpm
bash: https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release: No such file or directory
ix@pwrg:/media/ix/ledgers/.src$ sudo rpm --import https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release && rpm -K rippled*.rpm
rippled-0.70.2-1.fc25.x86_64.rpm: rsa sha1 (md5) pgp md5 OK
ix@pwrg:/media/ix/ledgers/.src$ sudo alien -i --scripts rippled*.rpm && rm rippled*.rpm
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_prep
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
    xargs -0 -r -i cp -a {} debian/rippled
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
dpkg-deb: error: control directory has bad permissions 777 (must be >=0755 and <=0775)
dh_builddeb: dpkg-deb --build debian/rippled .. returned exit code 2
debian/rules:17: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 1
ix@pwrg:/media/ix/ledgers/.src$ chmod 755
bitcoin-abe/                      rippled-0.70.2-1.fc25.x86_64.rpm
ix@pwrg:/media/ix/ledgers/.src$ chmod 755
bitcoin-abe/                      rippled-0.70.2-1.fc25.x86_64.rpm
ix@pwrg:/media/ix/ledgers/.src$ chmod 755 rippled-0.70.2-1.fc25.x86_64.rpm
ix@pwrg:/media/ix/ledgers/.src$ sudo alien -i --scripts rippled*.rpm && rm rippled*.rpm
Package build failed. Here's the log:
dh_testdir
dh_testdir
dh_testroot
dh_prep
dh_installdirs
dh_installdocs
dh_installchangelogs
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
    xargs -0 -r -i cp -a {} debian/rippled
dh_compress
dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
dpkg-deb: error: control directory has bad permissions 777 (must be >=0755 and <=0775)
dh_builddeb: dpkg-deb --build debian/rippled .. returned exit code 2
debian/rules:17: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 1

How to fix the error? Am I right that rippled allows me to run full rippled rpc server like bitcoind?

error: control directory has bad permissions 777 (must be >=0755 and <=0775)

Could it be a permissions problem?


How to get Master Private key in electrum wallet I have a wallet in electrum. I would like to get my wallet master private key. I don't know how to get that. Please, anyone, suggest me steps to get my key

Thanks in Advance

There are a few ways to do this:

If you're on linux or macosx you can do so via the command line:

electrum getmasterprivate

Alternatively run electrum and go to wallet menu > password to remove your password temporarily. Then go to view menu > show console and on the console tab use this command to view your xprv:

wallet.keystore.xprv

Then set a password again via wallet menu > password.

Note that there is another console command wallet.keystore.get_master_private_key('yourpasswordhere') that lets you do the same thing without having to remove the password first but the downside of that is that your password is saved in console history (specifically config file in electrum data directory) and can be scrolled through by pressing the up arrow while on the console tab.


Is there any where to get free testnet Bitcoins? I'm building a project with bitcoins and want to test it with testnet. However, I don't have any testnet bitcoins, and despite the difficulty being less than 100 usually, I still haven't been able to mine a block on my PC (CPU only) after a day. Is there anywhere I could get just some small amount of testnet bitcoins for testing?

Looks like you can get some here:
https://onchain.io/bitcoin-testnet-faucet
The term "faucet" has been used for quite some time for a site giving away small quantities of coins for free. If the above link ever stops working, a web search for "bitcoin testnet faucet" may find a different site.


Is it possible for computing power to increase quick enough to break mining retargeting? So from what I understand,  mining bitcoins basically becomes more difficult as more bitcoins are mined.  This is done so computing power doesn't get so strong that bitcoin mining becomes trivial to the point where people could mine 100's of bitcoins a day using their cell phone, for example.

Assuming that my understanding is correct,  do any of you math wizards out there know if there will ever come a time when the computing power is strong enough to make the mining time insignificant, or will the blockchain always be ahead so to speak because it becomes more complex as more bitcoins are found/rewarded/whatever?

Very curious about this.  Thank you for any answers.

The difficulty of the mining algorithm is solely reliant on the time it takes to mine 2016 blocks and the previous difficulty. (See: How is difficulty calculated?).

As the mining algorithm retargets exponentially (up to a factor of 4) every 2016 blocks, it is impossible for technological progress to outpace difficulty increase in the long run. Even if the mining power were to double every day (which is insane!), the block interval would only go down to about every two minutes in average, i.e. approximately five times faster.

On another answer I've provided a sample calculation for an overnight hash power increase by factor 21, which you might find interesting. The difficulty would catch up in 14 days.


Import multiple watch-only addresses using importaddress? With the importaddress RPC command it is possible to import one watch-only address.
But how can I do that with, let's say, 100?

The RPC interface doesn't generally provide any "batch mode" functionality.  If you want to import 100 addresses, call importaddress 100 times.  You might like to write a short script with a loop in some other language.

You should set the rescan parameter to false for all but the last address, so that you don't trigger rescanning 100 times.


Is a private key used up when part of the bitcoins it controls are sent? Here is my current understanding of Bitcoin:

I have 10 bitcoins in my wallet.

If I send 5 bitcoins to someone else, I am sending the private key from my wallet to somebody's public key address.

Those are combined into a new transaction that is later confirmed by miners. The miners confirm that I owned the bitcoins by checking my private key, and that the receiver's public key is valid.

Then, the miners create a new private key that is sent to the receiver's wallet.

On a simple True/False basis, is everything I have said right so far?

If so, what happens to the remaining 5 bitcoins in my wallet?  Do they magically get a new private key, or what? How does my wallet know how many I have left, and how do the remaining bitcoins get a new identity?

False, as you've described it here, because private and public keys work a little differently than that.  The underlying math is tricky, but I'll try and give a common sense explanation in everyday language instead.

Imagine that there was a special metal called Cryptonium, harder than anything else on earth and completely indestructible.  No one else knows it exists, much less how to make things out of it.  Let's also say you had a special machine which could make plaques out of Cryptonium, with raised letters on them saying whatever you wanted.  Obviously, you would keep the existence of this plaque-making machine a closely guarded secret.  You probably wouldn't even want anyone to know it was you that owned it.  But you still want to share this exciting discovery with the world, so you secretly produce a message that says "Behold, a new and indestructible metal!"  Then, late at night, you sneak into the middle of town and put the Cryptonium plaque up in the town square.

The next day, everyone gathers in the town square to wonder at this amazing new plaque.  They take turns bashing at it with the hardest, sharpest, heaviest things they can find, and the plaque remains perfectly unscratched.  "Sure enough," they figure, "it's indestructible."

You decide to use the secret machine to write more things, helping out the townspeople and gradually earning a reputation as a trustworthy and reliable source, even though nobody knows who you are.  But a few months later something terrible happens.  New plaques start showing up in town during the night, and they are fakes!!  Someone else is taking advantage of your reputation to spread false and misleading messages!  They don't have your special machine of course--they're making their plaques out of platinum, and it's only almost indestructible.  But the two metals look the same, and the townspeople don't know the difference.  What will you do?

You could announce yourself to the townspeople, show them the machine, and tell them the new plaques are fakes.  They might believe you, but your machine wouldn't be a secret anymore.  So instead you do something really clever.  You use the machine to make a small, square plaque in the shape of a hammer's head.  On the plaque, you put the message "This hammer will destroy all fake plaques." Then, you attach a handle to the hammer head you've made and leave it in the middle of town the next night.

Now, the townspeople can simply use the hammer to break all the fake platinum plaques.  Sure enough, the false and misleading messages are all easily destroyed, while the ones you've produced are able to withstand the hammer's force.  Your reputation is preserved, and your secret was never revealed.  Together the hammer, the secret machine, and the plaques form an unbeatable system that lets you send messages which could only have come from you--without revealing who you really are.  Not bad, hey?

In many ways public key cryptography works like our imaginary Cryptonium metal.  It's made up of three parts, and it gives other people a way to be certain a message came from you without you having to reveal your identity or your secret way of making messages.  Like the Cryptonium system, you need all three components to make the system work.  These three parts are your public key, your private key, and your signatures (which you can make as many of as you like, signing all different messages.)  In our story, the private key is like the secret machine, the public key is like the hammer, and the signatures are like the plaques.  In reality public key cryptography is more complex than I've described here, and if you want to learn more about it you can check out this course from Khan Academy.  However this example should be good enough to understand how private and public keys are used in Bitcoin.

First, nobody else ever sees your private key. Instead, like the secret machine, you use your private key to make signatures (like the plaques) that people can be certain came from you.  Each person (and each bitcoin address) has both a public and a private key, which share a special mathematical relationship, and the public key (like the hammer) is what other people can use to verify your signatures are real.  When you send a Bitcoin transaction, you don't give away your secret machine--you only use it to make a message saying who you're giving the bitcoins to.  This signed message, or signature, couldn't have come from anyone else except the owner of the address, so then everyone knows the transaction is real.

Second, private keys don't come from miners--they come from you.  You're the one who secretly chooses a random private key (the Bitcoin software does this for you), and that private key was used to figure out your address (which is basically a version of your public key) before anyone ever sent it some bitcoins.  Miners never have it to begin with.  They only see your transactions (signatures) and your receiving address (public key).

Finally, just to confuse things a little bit, you have to use up a whole transaction at one time.  So if someone sent you 10 bitcoins, and you want to send someone else 5 of them, you actually send out a transaction that takes all 10 that you received, sends 5 to the other person's address, and 5 to another address of your own (this is called the "change" from your transaction).  Bitcoin does this so that other people can't tell which part of the transaction is what you sent and which part is the change (nobody knows which addresses belong to the same person).  It helps protect your privacy.  But if you wanted to, you could send the change back to the same address, because your private keys are still safe.  You'd just have to use a different client than the default Bitcoin client, because it doesn't have a way to do that.  All of this happens behind the scenes, which is why your balance still shows as 5 bitcoins after you do this.  Bitcoin stores all your different addresses and private keys in something called a wallet, and the balance is the total bitcoins owned by the wallet.  So it keeps everything simple up front!

Make sense?  Hope it wasn't too long, but I wanted to try and make the public/private key thing more clear.


How to restore redeem script from a spent transaction? What is the procedure to restore redeem script of P2SH address from a transaction sent from that address? The script is stored on the blockchain in the tx data, the question is how to extract it?

If the P2SH output is already redeemed, then the transaction that spent it must have provided the redeemscript with the scriptSig in the outpoint to that P2SH output.

The last push of data in the scriptSig contains the whole redeemscript (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#Specification).

E.g. for a multi-signature the scriptSig that spends the output will be of the form:

scriptSig: 0 [signature1] ... [signatureM] {M [pubkey1] ... [pubkeyN] N OP_CHECKMULTISIG}

Where everything inside {...} is a push of that redeemscript which you just have to extract.


How may I get paid with a free bitcoin website? In what ways may I monetize a website which offers free and accurate real time Bitcoin exchange and BTC market meta data?

In this particular case the purpose and the business model the website was built for is a longer term proposition. In the meantime how can this website be enhanced to return at least some revenue while not substantially diminishing the intrinsic value of the content?

About the content one recent user said "Wow – I went through most or all of the site, I can see you have a lot of thought into this, and a very nice informative site it is."

I am brainstorming for a complete array of all possible - and legal - options. Any idea in its kernel form could be what I need "how may I get paid with this website?" - so add your answer now :)

One way in which I have seen many such websites monetize their services is to release paid APIs. There would be people willing to pay to use your APIs (for trading, news services, Apps etc) if the data is better than the ones that are freely available.

On top of this you can try the usual stuff, ads and referrals and such things on your website.


Is Bitcoin a mesh network? Considering following definition, can we say that bitcoin is a mesh network?

    A mesh network uses a network topology in which each node (called a mesh node) relays data for the network. All nodes cooperate in the distribution of data in the network. http://en.wikipedia.org/wiki/Mesh_networking

It broadcasts blocks and transactions using a logical mesh network, but that shouldn't be confused with physical mesh network proposals.


How big is the input of a P2PKH transaction? How many bytes does a P2PKH input have? I'm finding a few different numbers:

Why does the default miner implementation use pay-to-pubkey? states:

  push + sig + push + key = 1 + 72 + 1 + 61 = 139

Princeton Bitcoin Book states [p.123]:

  The approximate size of a transaction is 148 bytes for each input[…]

A knowledgeable Bitcoin developer calculated from the top of the mind for me over coffee:

  PREVOUT + SCRIPTSIG = 36 + (1 + 1 + 33 + 1 + (71 or 72)) = 143 or 144

I couldn't find further information in the Bitcoin Developer Guide or the wiki.

Bonus-question: How come there are different numbers? Did the size change over time?

The first number does not include the prevout, sequence number, or the length byte for the scriptSig. It also uses 65 bytes for the public key (which is correct if it is uncompressed, but compressed keys of 33 bytes are more common now). Correcting it gives 139 + 36 + 4 + 1 + (33 or 65) = 148 or 180.

The developer in the third case forgot to include the sequence number, making the result 147 or 148 for compressed public keys and 179 or 180 for uncompressed public keys.

The guys at Princeton clearly know best.

So to summarize:

PREVOUT: hash (32 bytes)
         index (4 bytes)
SCRIPTSIG: length (1 byte)
           CONTENTS: push opcode (1 byte)
                     signature (71 or 72 bytes)
                     push opcode (1 byte)
                     pubkey (33 bytes for compressed, 65 for uncompressed)
sequence (4 bytes)


The bitcoin opcode seems to have a flat rate The bitcoin opcode seems to have a flat rate, is that correct?
Or, if bitcoin has a price per opcode, please give me the link.
If it is a flat rate, please tell me why bitcoin does not have a mechanism like ethereum.

If by "flat rate" you mean that each opcode costs the same amount in transaction fees, then yes, Bitcoin does have a "flat rate". Opcodes don't have a direct fee themselves, the fee is based on the size of the transaction, and since each opcode is one byte, they have the same cost.
It is unnecessary to have an opcode cost scheme like Ethereum because opcodes are not very computationally expensive and do not have the same effects as Ethereum opcodes do. Bitcoin script is not Turing complete so it is impossible to loop. Each opcode can only be run a single time.
Furthermore, the more computationally expensive signature verification opcodes do have an additional cost in the form of the "signature operations" (sigops) limit. Sigops are factored into the calculation of a transactions weight which will then effect the transaction fee, but this effect is only present in extreme cases where there are a lot of sigops in a single transaction. Blocks are limited in the number of sigops that they can include.


GetAddr not returning connected node addresses I am writing a simple program that connects to nodes in order to index them, kind of like blockchain.info nodes works. Doing this in GLang using the btcd/wire library to create the messages, the message sequence is as follows:

Version ->
<- Version
<- Version Acknowledge
<- Ping
Pong ->
GetAddr ->
<- Addr

However upon reading the list of addresses returned they all are either empty or contain a single address that corresponds to that nodes address (I.E. it returns its own address).

From reading the wiki I know nodes only return addresses of connected nodes that have a timestap less than 3 hours ago, and that there are certain dns nodes and seed nodes. Are there any nodes that will always return connected peers regardless of their age? Or any way to bootstrap the process? How does a normal full node connect to more than a handful of nodes when these may never return anything (if they have been alive for more than 3 hours, then they will only return something on new connections)?

What worked for me was sending a ping message. Also, the addr message didn't come directly. I had to keep listening on the same port for at least a second.

You can use the dns seeds as a starting point, however a large portion of nodes might still only give you their own address. If anyone knows why I'm curious to hear, but I think every client just has its own way of dealing with these messages.

Version ->
<- Version, Verack
Verack ->
Ping ->
GetAddr ->
<- Pong, Ping, ManyMoreThings
<- Addr


Bitcoin Core Multi-wallet limit to 333 wallets Bitcoin Core 0.15.1 has Multi wallets support:

In the bitcoin.conf we can add multiple entries of:

wallet=wallet-1.dat
wallet=wallet-2.dat
wallet=wallet-3.dat
wallet=wallet-4.dat
...
wallet=wallet-350.dat

When Bitcoin Core starts, if the wallet file does not exists it will create it. which is great for our needs.

However, it always crashes on the 333 wallet. with db.log error:

Lock table is out of available locker entries

And debug.log:

2018-02-13 14:47:05 init message: Loading wallet...
2018-02-13 14:47:05 nFileVersion = 160000
2018-02-13 14:47:05 Keys: 21 plaintext, 0 encrypted, 21 w/ metadata, 21 total
2018-02-13 14:47:05  wallet                   36ms
2018-02-13 14:47:05 setKeyPool.size() = 20
2018-02-13 14:47:05 mapWallet.size() = 0
2018-02-13 14:47:05 mapAddressBook.size() = 0
2018-02-13 14:47:05 init message: Loading wallet...
2018-02-13 14:47:05

************************
EXCEPTION: St13runtime_error
CDB: Error 12, can't open database wallet-333.dat
D:\BitcoinCore\bitcoin-0.16.0\bin\bitcoin-qt.exe in Runaway exception

I also tried to minimize the -keypool=20 so that the wallets size will be much smaller in size, and the process of loading them is much faster.

I was suggested that this error is because each wallet.dat file is opened in the same BDB environment. The entire environment has a limited number of database locks, and it seems like 333 wallets hits that number of database locks.

The solution (which did not work) is to create a file named DB_CONFIG in the data dir, and put the following lines in that file:

set_lk_max_locks 400000
set_lk_max_objects 400000

By default it is 40000 and now 400000 (ten times more locks available)

But this gave the same results.

I tried also:

set_lg_dir database

With no luck.

I verified this on two different Windows 10 machines with 0.15.1 and 0.16.0. Same result. It always crashes when loading the 333 wallet.

Anyone have a solution to this?

I have put the list of wallets if anyone care to reproduce: https://pastebin.com/8wHD1tL3

Ok, I found a solution. Adding

set_lk_max_lockers 400000

Did the trick.

https://docs.oracle.com/cd/E17276_01/html/api_reference/C/set_lk_max_lockers_parameter.html

I tested and was able to auto-create and load 932 wallets, until I hit an out of memory error:

Logging region out of memory; you may need to increase its size
DB_TXN->abort: log undo failed for LSN: 227 171878: Not enough space
PANIC: Not enough space
PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
PANIC: fatal region error detected; run recovery

Setting:

set_lg_regionmax 1048576

Resolves the above Logging region out of memory; you may need to increase its size issue.


Are there studies about a Bitcoin-like economy with inflation? Assume, we create an alternative cryptocurrency ("InflationCoin") based on the bitcoin software with one change to the protocol:

The Block reward is constant, e.g. 50 InflationCoin

Technically this would work just like Bitcoin while avoiding one of Bitcoin's most discussed characteristic, namely built-in deflation. The supply of InflationCoin would grow constantly, possibly leading to a controlled and predictable inflation if the InflationCoin economy does not grow as fast the supply of InflationCoins. Transactions are always cheap and therefore encouraged. Hoarding is dangerous due to the risk of inflation.

Since, both unsing Bitcoin and InflationCoin is voluntary, they could coexist and possibly attract different users or usage scenarios.

The alternative blockchain Freicoin is a solution to the "deflation-causes-hoarding-problem" (assuming that you think this is a genuine problem) using demurrage rather than inflation.

As for your proposal of making the rate of money growth linear and higher than the expected rate of InflationCoin economy growth, that would accomplish the same goal: punish those who put their savings in coin rather than something productive like stocks and bonds.

According to Gresham's Law, Freicoin and InflationCoin should flourish as a medium of exchange and Bitcoin velocity should collapse as people tuck those relatively scarce coins away in wallets like they're bars of gold.

Of course, this isn't in fact happening. Maybe that's because of network effects (who accepts payment in coin of alternative block chains?) Or maybe the deflation theory is wrong.


How is blockchain not responsible for someone stealing my Bitcoin? I'm new so please forgive me if I'm just not getting this. I have done nothing wrong. I did all the 2fa all recovery phrase I was told to do. I wake up to see 1200 dollars in crypto just gone from my account. It's weird the moment I set my recovery phrase was when my money disappeared. Blockchain hasn't said anything but oh well this is what happens. So I do all the things I'm supposed to and I lose money that I don't have with noone to help me get it back? I mean if I have to send in all my identity documents doesn't everyone? I see where it was sent cause it's public and NOONE can tell this thief that they need to give my funds back? I'm not well and my husband isn't well at all. We received this money as  payment for work my husband done on a house we been waiting for and it's just gone and nobody can tell me anything. I didn't get an approval from blockchain for entering my account no sms verification code sent to my phone. So is it blockchain itself? Just glancing at messages I see blockchain alot with this issue. I'm devastated I don't know what to do. I hoped maybe I sent to a offline storage or something but I have no idea. Can anyone please tell me what happens when you set up the recovery phrase did that automatically send my coins somewhere or did I just get robbed? I just want to stop wondering and get past this and leave cryptocurrency alone

How is blockchain not responsible for someone stealing my Bitcoin?

Many people have asked similar questions here concerning theft and recovery but I think the question of responsibility is a good one.
This answer makes a few digressions but I hope by reading to the end, the issue of responsibility will be clearer.

Unexpected transfers

Can anyone please tell me what happens when you set up the recovery phrase did that automatically send my coins somewhere

No. That wouldn't be normal.

Control of cash
It is probably useful to clear up a few basics.
If you live in the USA, when you go to a coffee shop and pay cash in paper dollar bills or coins for a cup of coffee, this obviously does not involve the car rental business called Dollar (website: dollar.com) even though you are paying in dollars. If there was a bank called Dollar Bank Inc, your use of paper dollar bills and coins to buy a cup of coffee would have nothing to do with them.
Businesses like blockchain.com or bitcoin.com are not in control of bitcoin. Just as dollar.com is not in control of the US dollar. You don't have to use those businesses (or any others) to use bitcoins (or dollars)
Bitcoin was created as electronic cash that does not depend on trusted third parties like banks.
From what you write, you chose to give your money to a company named blockchain.com. If you are unhappy with their service or feel they have failed to take proper care of the money you gave them, that is something that you must take up with them. No-one else has any special inside knowledge of what that business does.

Theft

It's weird the moment I set my recovery phrase was when my money disappeared.

It seems likely that someone else saw that recovery phrase and used it to take control of your money and spend it. Maybe your computer or phone has been infected with malware that lets a criminal spy on your use of it using a software keylogger or some other malicious technique.

Responsibility

I see where it was sent cause it's public and NOONE can tell this thief that they need to give my funds back?

That is correct. Bitcoin is mostly anonymous. You can see an address where money was sent but there is no central registry of who controls which addresses. The addresses all look like random numbers. Bitcoin is a peer-to-peer cash - which means there is no central authority who can intervene to reverse transactions.
This is the nature of cash. If you are walking through a train station or airport and a pickpocket removes a paper $5 bill from your pocket without you noticing. The next day there's no government agency and no bank you can ask to press a button that will put that paper $5 bill back into your pocket. Cash doesn't work like that.
If you feel you have evidence you have been robbed. you should report it to your local police. That's what you would do if a pickpocket stole the cash in your pocket.

Recovery
You will get lots of offers for help but all of them will be from conmen and scammers who are trying to get you to trust them so they can trick you out of more money. They will eventually try to confuse and panic you by talking about refund fees, release fees or the need to prime a wallet with money and lots of other lies.

Related Questions

How do I recover from a cryptocurrency scam?


PSU for Bitmain Asic miner I have a S3+ ASIC miner and 500w PSU
My question is that what do I need to convert a 4+4 PCI-E into a 6+2 PCI-E or two 6+2 PCI-E.
Thanks in advance

Use a converter cable. They have so many on amazon: http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=pci-e+converter+cable&rh=i%3Aaps%2Ck%3Apci-e+converter+cable


When a transaction will reject if the fee was to low? I would like to know when a transaction will reject if the fee was to low to be confimed.

If this transaction never will be rejected, what is to do to delete this transaction?

The minimum fee for relaying a transaction through the peer to peer network depends on the peer policy. It's up to the node (peer) operators to set the minimum relay fee.

Since Bitcoin Core uses a maximum mempool limit (before it was unlimited), this minimal relay fee will auto-adjust.

It's difficult to say feerate (fee per byte) x is the minimum fee required fee for the network.

And, later, you want that your transaction get mined, which is different from transaction propagation through the network.

This depends on the miners. They have full control if they include your transactions into a block or not.

If we assume, they act rational following financial incentives, then the higher your fee is, the more likely is, that it will be included.

It also highly depends on what other transactions in the mempool uses what ferrates.

EDIT:

deleting transactions as a user action is impossible, though you can assume, that over time, the transaction will vanish from the mempool(s) due to size limitations.
Best thing you can do is use RBF BIP125 (replace by fee) to ensure you have the capabilities to later replace the transaction with a new transaction paying higher fees.
In case your old (stuck) transactions hasn't signalled BIP125 RBF, then child pays for parent may help (CPFP, maybe google it). The concept there is that you use the change output of the stuck transactions as an input for a new transaction and use "relatively high fee" (pay for the missing fee and the new transaction). Therefore a miner likes to include that transaction (because of the fee incentives), but, needs also to pick the older (stuck) transaction.


hash locked multisig, can one cosigner sign without the pre-image? Consider Alice and Bob created the following native segwit script:

hash SHA256 defined as H | Alice PubKey | Bob Pubkey

Only Bob has the pre-image (plain text that hashes [sha256] to H). Can Alice just sign a transaction without revealing H, and just hand over the partially signed transaction off chain to Bob so he can reveal H + add his signature, make the transaction final and spend it?

The catch here is that neither Alice and Bob to be in total and exclusive control of the funds, but for Bob to have to reveal an additional secret as spending condition.

Can Alice just sign a transaction without revealing H, and just hand over the partially signed transaction off chain to Bob so he can reveal H + add his signature, make the transaction final and spend it?

Certainly. Of course the software will need to know how to handle that data, but it is not that hard to do.

The pre-image is not used in signing in any way; it is just additional data required by the script in order for the script to validate correctly.


What is the right way to accept bitcoin payments using bitcoind? I want to implement payments using Bitcoin without any 3rd party services. I already installed full node on my server and configured RPC API. What should I do next?

Now I plan to work in the following way:

Create wallets for all existing and new users using getaccountaddress method and store address in DB.
Set up an every minute cron job which will calls listtransactions * 1000, loop through transactions to find new which has more than N confirmations.
Store filtered transactions in DB, find user by address and add money to balance.
Send received bitcoins to another (main) wallet using sendfrom method.

I have some doubts about the stability of the solution. I do not think that users will perform more than 1,000 transactions per minute, so when all is working as planned, it looks as pretty stable solution. But what, if, for example, bitcoind (or entire server) will hang / fail / break down? How easy will be to handle payments that were not processed before?

Maybe there is a better way for receiving payments? Thank you.

You should check out walletnotify: everytime a transaction hits your wallet it will fire a command or script off.

  Walletnotify will run a shell command everytime something changes in your wallet.

I like this repo.


What are the possible Doomsday scenarios for the 2016 Halving from 25 to 12.5 BTC per block solved? The 2016 halving is coming from 25 to 12.5 BTC solved for every block. For us to understand the effects. What are some possible doomsday scenarios that can happen?

I think you might be referring to the hypothesis that a large portion of the mining power would switch off right at the halving. This is theorized to kick off a chain reaction:

Lower network hash rate causes slow blocks
Slow blocks increase block space competition
Block space competition increases fees
Increased fees push users off network to competing coins
…
Bitcoin fails

I think this theory is a bit of a slippery slope:

Hashrate

More than half the hashrate has only come on-line in the past half year. Mining companies should be well aware of the Halvening and I'd expect them to consider it in their financial planning. Some might miscalculate its effect, but it shouldn't come as a total surprise.

I'd expect investments into mining hardware to slow down in the time before the Halvening, and mining companies to keep close watch on their revenue immediately after it. They'd first turn off the least efficient hardware, which reduces their cost the most and also has the least impact on their hashrate. Every piece of hardware that gets turned off makes the remaining hardware more profitable. It may dip, but gradually would find a new balance.

Similarly, some altcoin might be more profitable suddenly. Yet, as mining power switches over, competition for that altcoin's revenue gets more fierce, while the reduced hashrate in turn makes Bitcoin more profitable for the others.

Block space
More competition to enter the blockchain would not end the world. In some subreddits the narrative seems to be that full blocks would necessarily cause unconfirmed transactions to grow limitlessly. However, it seems much more likely that people would consider their transactions more carefully, and block space would be used more efficiently. E.g. major Bitcoin companies that do two transactions per payout would probably find a way to save some of those, mining pool minimum payouts might increase, you'd combine transactions where possible. Besides, it seems likely that SegWit would be deployed by then and block space might be less of an issue in general.

Competing coins
Bitcoin is the coin with the greatest security and utility. Paying premium for a feature that you don't need seems silly. If people move to other coins for low amount transactions, one or two of them might see a renaissance, but they wouldn't be able to overtake Bitcoin because they'd have all the same problems with scaling, governance, and software evolution once they get a similar amount of attention.

TL;DR: If the network's hashrate dips, it seems unlikely to happen instantaneously. It may decrease a bit over time. The resulting pains would incentivize more efficient behavior, but I don't see how they'd cause Bitcoin to fail.


Does bitcoin have transaction fees? Does bitcoin have transaction fees when sending money from on wallet to another ? How much % is the fee ?

Yes, Bitcoin transactions have transaction fee. It is not proportional to amount of Bitcoins sent, but it is proportional to the size of transaction and it is measured in satoshi/byte. (10^8 Satoshi is 1 Bitcoin)

The fees changes from time to time because of market conditions. You can find a good idea of what fees to pay on this site https://bitcoinfees.21.co/.


How many currency units in 1xBTC / 1xAltCoin? Since BitCoin (and AltCoins) are divisible by up to 8 decimal places, does that technically mean that 1xBTC (or 1xAltCoin) is equal to 1 billion individual units of currency?

No, at least not for the original Bitcoin and all those altcoins that do not change this aspect. But you are almost correct: Each Bitcoin is divisible into 0.1 billion (which is 100 million or a 1 followed by 8 zeros) actual units, called Satoshi after the pseudonym of Bitcoin's creator. In fact, the protocol only uses these; displaying them as Bitcoin is purely an output formatting convention.


What's the best way to introduce Bitcoin to the family and friends? What's the best way to introduce Bitcoin to the family and friends?
Has anybody succesful experience in the topic?

I don't know the best way. But what I do is talk about it all the time. And actually use the bitcoins. I mean purchase things with your bitcoin not trade with them on exchange networks.

I buy a new product with my bitcoins and use it in front of my friends and family. Those who are interested ask where I got it, and then ask how much I spent on it. My response is in bitcoins. eg it was just 0.10 bitcoins very decent deal. Or it is just 2 bitcoins.

I've found that when selling an idea of bitcoin by saying things like 0.10BTC is worth $60.00 today I tend to get strange looks. Like so you spend $60.00 on 10 cents? People have a hard time understanding concept of ForEx and values of money when comparing one currency with another. It is more successful when you buy something and explain that you purchased it with bitcoin.

Also Christmas is coming up. And I've made paper wallets loaded with bitcoins. And on the paper wallets I have a list of websites that accept bitcoins as payments. So it is like a gift card and it helps people get the idea of what bitcoin is.


creating a fork of bitcoin, how to modify core to create my own network I'd like to make a fork of Bitcoin, since it's the new trend ;)

The first thing I did was to create a docker image of ubuntu with all the dependencies, then I wanted to run the core software- but the first thing it did after I built it and booted it up was start trying to connect itself to the real-world bitcoin network- not what I want!

What I'd like to do is define my own network, that I can just run on some machines that are under my own personal control- pass around coins- all the typical stuff- check out the wallet- really basic

but I'm at a loss for how to do that.

I've been told that I need to modify chainparams.cpp, is it so? If yes, then what do I need to do to it?

Is that the only thing I need to change? if there are other things what are they?

Regtest should really suffice for your basic testing. If you really want to modify chainparams, you would first start with the DNS seed data in the file; these are hard coded.


Bitcoin core, wallet is empty? So I have a bitcoin core wallet. And I bought bitcoins and filled out the address under, I think the english word for it is: reception addresses.  see picture. I assumed this was my wallet address. Everything went well with the transaction. I can see there is send money to this address. But my wallet is still empty after 4 hours. Can someone help me with this?

Your client is currently unaware of the transaction on the bitcoin network because it is not synced with the bitcoin network.  Wait for the green progress bar at the bottom of the client to complete.  Once your client is aware of the transaction it will show your appropriate balance.


Access my account only to the previous Bitcoin URI number '
I entered the https://bitcoincore.org site, made the downloads and installed my wallet, which was working but did not back up. He gave a problem on my PC and I had to format the drive. I re-download and now I'm using the new URI Bitcoin number .How can I access my account only password and to the previous Bitcoin URI number?

Sorry to inform you, but you cannot. If you've lost the data of the previous installation without a backup, the money is gone. You need access to the private keys stored in wallet.dat to spend money received to those addresses.


SegWit transaction fee/byte For transaction not spending SegWit outputs it's straightforward: if I have 1000 Satoshi fee set for 500 byte raw transaction, I end up with 2 s/b fee.

How about transaction containing witness data?

Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

That's not correct.

SegWit replaces the concept of size and maximum block size with weight. The weight of a transaction is defined as 3 times the stripped_size in bytes (excluding the witness) plus the total_size in bytes (including the witness). The maximum weight of all transactions in a block is 4000000. This is the only limit that matters. Due to the way the weight formula is constructed, it implies that the old rule (stripped_size <= 1000000) is always satisfied. Miners try to get as much fees out of the weight limit they have available, and as a result optimize for fee per weight.

So, transaction sizes don't matter anymore. What matters is their weight. Unfortunately, there is a factor 4 scaling between the two, so you can't easily convert feerates from before SegWit to after. For this reason, the concept of vsize (virtual size) was introduced. It's equal to weight/4. For non-SegWit transactions, their size and vsize are identical. The easiest way to express fees is now to see them as BTC per vbyte (vsize byte).

  How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

In your example, the weight of your transaction is 3*400 + 500 = 1700. This means its vsize is 425 vbytes. As a result, its feerate is 1000 / 425 = 2.35 sat/vbyte, and it would compete with other transactions at that level.


How do the miners earn money after 2140 on no-transaction-block? A block can embedded no transaction, miner gets no fees for this block.
So, how do the miners earn bitcoin/money after 2140 on no-transaction-block?

thanks,
-baco
(a back-to-the-future-man from december 2139)

Simple: they don't.

It's not in the best interest of the network for miners to mine zero-transaction blocks.  It means that the transactions in the mempool will have to wait for the next block to be solved before being included.  This phenomenon of blocks with no transactions is a product of the block reward still being so relatively high.  As it decreases, miners will rely more on transaction fees for their incomes, and we will see fewer and fewer zero-transaction blocks.


How often does a block have only one transaction? I was looking at blocks on blockchain.info, and came across this one with only one transaction in it: (the mining reward one)

https://blockchain.info/block-index/512049/00000000000000000429a0c4fbe735b2d8b493daedf0207728543f748c262437

Is that at all suspicious? Does it mean someone was trying to block some transactions from going through? How common are single-transaction blocks?

It's possible that this could happen just because there aren't any transactions to be mined. Early on in the bitcoin block chain, this was often the case. This could also happen if two blocks are solved on top of each other in a very short amount of time, with not much time for new transactions to be broadcasted in between. Today, however, more often than not this is due to a miner trying to get his/her block out to the rest of the peers on the network as soon as possible.

A miner would want to do this because bigger blocks take longer to propagate to the rest of the network. Nodes have to download and verify the validity of a block before they can relay them to their peers, because if they don't verify before sending and they send an invalid block, then their peers may ban them and the node will have no one to connect with on the network.

Think of it this way. If your block takes 50 seconds to get out to 90% of the peers on the network, and someone else mines a block 1 second later than you but can get their block out to 90% of the network in 9 seconds, who do you think will have the greater chance of getting their block accepted by more peers?

It may also be worthwhile to note that while this seems like it has a better pay off, it also sends a message to everyone on the network that the miner who mined the block doesn't really actually care about the bitcoin network's transactions, it just cares about its reward. And if the miners don't support the system, then why should investors or anyone else have confidence in it? I guess what I'm trying to say is that if a lot of miners did this, then the price of bitcoin would likely drop as it would show a lack of faith in the system.

There's a more mathematical analysis of orphan rates and payoffs here: http://organofcorti.blogspot.com/2013/10/161-network-orphaned-blocks-part-1.html\

In addition, it may interest you to know that there is a new proposal to enable faster propagation of blocks even if they are very large. See here for more info: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2.

A different way of explaining this would be that, for a block to be accepted by the network, it has to be propagated out and checked by everyone. While blocks are spreading through the network, any miners who don't know about the new block will just keep mining on the block they have. In most cases, probably, this is just wasted work since there is already a block that is on it's way to being accepted. But if your block is much smaller (i.e. very few txs), then it gives other miners less time to solve a block while yours is propagating, and it also increases your chance that your block will get accepted by the majority of the miners even if someone else solved a block slightly before you.

To answer this question with a bit of data, I made a script that processed the last 1 month of blocks (4,464 blocks before and including block 338,782), and gathered data about the number of transactions in each block. These were the results.

  From this data, it seems that roughly

  1.3% of blocks are solved with just the reward transaction
  1.6% of blocks are solved with fewer than 10 transactions.

# Transactions  # Blocks with transaction count in MIN-MAX range
MIN     MAX     COUNT
0       9       73
10      19      31
20      29      22
30      39      74
40      49      52
50      59      43
60      69      107
70      79      50
80      89      41
90      99      56
100     109     55
110     119     50
120     129     86
130     139     46
140     149     54
150     159     57
160     169     51
170     179     62
180     189     49
190     199     53
200     209     46
210     219     45
220     229     64
230     239     42
240     249     45
250     259     69
260     269     58
270     279     39
280     289     41
290     299     41
300     309     44
310     319     45
320     329     37
330     339     35
340     349     45
350     359     42
360     369     40
370     379     42
380     389     41
390     399     37
400     409     48
410     419     47
420     429     42
430     439     40
440     449     40
450     459     46
460     469     42
470     479     32
480     489     33
490     499     40
500     509     38
510     519     68
520     529     44
530     539     28
540     549     32
550     559     28
560     569     35
570     579     27
580     589     29
590     599     28
600     609     19
610     619     31
620     629     20
630     639     27
640     649     38
650     659     28
660     669     27
670     679     25
680     689     18
690     699     21
700     709     27
710     719     28
720     729     23
730     739     25
740     749     25
750     759     19
760     769     21
770     779     24
780     789     27
790     799     23
800     809     16
810     819     18
820     829     19
830     839     18
840     849     16
850     859     19
860     869     20
870     879     16
880     889     18
890     899     16
900     909     24
910     919     24
920     929     14
930     939     18
940     949     20
950     959     12
960     969     13
970     979     15
980     989     15
990     999     21
1000    1009    15
1010    1019    15
1020    1029    18
1030    1039    14
1040    1049    13
1050    1059    13
1060    1069    9
1070    1079    16
1080    1089    16
1090    1099    8
1100    1109    17
1110    1119    10
1120    1129    12
1130    1139    8
1140    1149    8
1150    1159    22
1160    1169    10
1170    1179    14
1180    1189    17
1190    1199    10
1200    1209    11
1210    1219    14
1220    1229    9
1230    1239    9
1240    1249    12
1250    1259    9
1260    1269    8
1270    1279    7
1280    1289    7
1290    1299    9
1300    1309    8
1310    1319    12
1320    1329    8
1330    1339    7
1340    1349    12
1350    1359    10
1360    1369    13
1370    1379    10
1380    1389    10
1390    1399    9
1400    1409    10
1410    1419    8
1420    1429    14
1430    1439    10
1440    1449    6
1450    1459    6
1460    1469    6
1470    1479    9
1480    1489    7
1490    1499    4
1500    1509    5
1510    1519    8
1520    1529    5
1530    1539    12
1540    1549    3
1550    1559    7
1560    1569    8
1570    1579    3
1580    1589    7
1590    1599    2
1600    1609    12
1610    1619    5
1620    1629    10
1630    1639    3
1640    1649    4
1650    1659    5
1660    1669    6
1670    1679    5
1680    1689    3
1690    1699    5
1700    1709    2
1710    1719    1
1720    1729    10
1730    1739    4
1740    1749    5
1750    1759    4
1760    1769    4
1770    1779    2
1780    1789    3
1790    1799    6
1800    1809    3
1810    1819    2
1820    1829    4
1830    1839    5
1840    1849    4
1850    1859    3
1860    1869    3
1870    1879    3
1880    1889    5
1890    1899    3
1900    1909    3
1910    1919    4
1920    1929    1
1930    1939    0
1940    1949    3
1950    1959    0
1960    1969    0
1970    1979    3
1980    1989    2
1990    1999    2
2000    2009    3
2010    2019    3
2020    2029    3
2030    2039    3
2040    2049    7
2050    2059    3
2060    2069    1
2070    2079    4
2080    2089    2
2090    2099    1
2100    2109    1
2110    2119    3
2120    2129    2
2130    2139    2
2140    2149    4
2150    2159    1
2160    2169    2
2170    2179    1
2180    2189    2
2190    2199    3
2200    2209    0
2210    2219    0
2220    2229    1
2230    2239    0
2240    2249    3
2250    2259    0
2260    2269    1
2270    2279    2
2280    2289    1
2290    2299    3
2300    2309    0
2310    2319    1
2320    2329    0
2330    2339    1
2340    2349    1
2350    2359    1
2360    2369    1
2370    2379    1
2380    2389    0
2390    2399    0
2400    2409    1
2410    2419    1
2420    2429    1
2430    2439    0
2440    2449    0
2450    2459    0
2460    2469    1
2470    2479    0
2480    2489    0
2490    2499    2
2500    2509    0
2510    2519    0
2520    2529    1
2530    2539    2
2540    2549    2
2550    2559    1
2560    2569    0
2570    2579    1
2580    2589    1
2590    2599    0
2600    2609    0
2610    2619    0
2620    2629    0
2630    2639    0
2640    2649    2
2650    2659    0
2660    2669    0
2670    2679    0
2680    2689    0
2690    2699    0
2700    2709    0
2710    2719    0
2720    2729    0
2730    2739    0
2740    2749    0
2750    2759    0
2760    2769    0
2770    2779    0
2780    2789    0
2790    2799    0
2800    2809    0
2810    2819    1
2820    2829    0
2830    2839    0
2840    2849    0
2850    2859    1
2860    2869    0
2870    2879    0
2880    2889    0
2890    2899    0
2900    2909    0
2910    2919    0
2920    2929    0
2930    2939    0
2940    2949    0
2950    2959    0
2960    2969    0
2970    2979    0
2980    2989    0
2990    2999    0
3000    3009    0
3010    3019    0
3020    3029    0
3030    3039    1
3040    3049    0
3050    3059    0
3060    3069    0
3070    3079    0
3080    3089    0
3090    3099    0
3100    3109    0
3110    3119    0
3120    3129    0
3130    3139    1

The x-axis here (it may be hard to read) is the transaction range (each MIN-MAX pair in data above represents one column). The y-axis shows the number of blocks in the last month that had a transaction count within the range.


Which security threats in P2PKH lead to the use of P2SH? To steal a P2PKH output you would have to find the private key of the public key that generated the hash used in the tx. This is impossible to do in a feasible timespan, therefore making the tx secure. What incentivized the use of P2SH? I'm particularly asking in the light of this paragraph of the Bitcoin developer guide:

  Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. Receivers do care about the conditions imposed on the satoshis by the pubkey script and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and more difficult to secure than P2PKH pubkey hashes.

I have been unable to find an example of a "reedem script", could you give one?

The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.

So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 out of a set of 5 keys to spend my coins. So, the scriptPubKey that I would like everyone to use when they send coins to me is:

OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG

But each pubkey is 33 bytes and so this makes a script that is ~170 bytes, which is a bit much to encode in a QR code. And it is definitely is too much data for a human to process.

But if I use P2SH, the scriptPubKey is just 23 bytes and the sender doesn't have to worry about what exactly the redeem condition I am setting on my coins is. P2SH works like this. I take the script that I want to be my scriptPubKey and I serialize it (I'll use {} to denote serialization):

redeemScript = {OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG}
redeemScript_hash = hash160(sha256(redeemScript))

And then the scriptPubKey that the sender actually uses is:

OP_HASH160 {redeemScript_hash} OP_EQUAL

Which is just 23 bytes in total. The nice thing is that it provides a layer of abstraction. The person who is sending me coins doesn't need to know how I am keeping my coins secure. All they see is a hash of a redeemScript, but they don't know what conditions that redeemScript actually puts on redeeming the coins.

Basically, P2SH itself is not inherently more secure because the redeem script can be anything. But what it does is enable coin-receivers to easily communicate how coin-senders should send them coins, while letting the coin-receivers dictate the conditions of how/when those coins can be spent.


Does a soft fork result in two different blockchain versions? I've read the following:

Both forks create a split, but a hard fork creates two blockchains
and a soft fork is meant to result in one.

Let's consider 2 situations:

block size max limit is 1mb and bitcoin introduced a new version which increased block size limit by 1, so it's 2mb now. Now, this is called hard fork, since new versions wouldn't be compatible with the old ones, because when new versions solve a block (let's say 1.5mb), old ones wouldn't accept it. (NOTE: if old ones send blocks to new ones (since old ones would only solve blocks with less than 1, new ones would always accept it)); So new ones can't communicate with old ones, but old ones can with new ones.

block size was 1mb and now, we decreased it by 0.5, so it's 0.5mb now. Now, new versions are compatible with the old ones, because, new versions would always solve blocks with 0.5mb or lower and when they send it to old ones, they would accept it. (NOTE: when old ones send blocks to new ones (since old ones might solve block with 0.8mb, new ones wouldn't accept it)); So, new ones can communicate with old ones, but old ones can't with the new ones.

Do you agree with the above? If so, why in my first sentence, does it say: that a soft work is meant to result in one ? It won't result in one, since when old ones solve blocks bigger than 0.5mb, new ones wouldn't accept it, so we still would have a different version of blockchains. Any idea?
UPDATE: @Murch, you say in the second one that since the small blocks(from new nodes) are acceptable to the old nodes, big block nodes will reorganize to the small block chain.
If 5% minority(which work on old big block chain) solves a block, only those 5% nodes will add it to their chains. 95% wont, since they have smaller limit on block size. Now, 5% minority nodes have the last block different from the last block of 95% majority.(length of both chains are the same - that could have been since after splitting the chains, 5% solved it in the same seed as 95% on their respective chain). if 95% majority now produces a new block, and share it to 5%, they still won't add it because  this newly shared block's prev hash won't match their last block's hash. So in this case, 95% majority will produce a newer block faster(at least now, the lengths are not the same), so now, majority will share 2-3 blocks to minority since they have the longest chain and that's why minority will adapt to majority's chain in the end. Is my explanation and understanding correct ?

Your observation is correct, except that a fork is expected to be activated by a supermajority of nodes and miners in the network. The most recent soft fork had an activation threshold of 950 blocks in specific segments of 1,000 blocks signaling readiness (95% hashrate) for the new rules.
So, assuming that only 5% of the mining power don't follow the new rules:

Increasing block size: 95% of the mining power allows bigger blocks now, 5% continue to enforce the smaller limit. As soon as a block with the new rules is found, the old nodes that do not allow bigger blocks reject the main chain and start their own chain-tip. The minority chain moves much slower, and thus the majority of the miners and nodes ignores it. Assuming the split's proportions remain stable, the two chains remain irreconcilable. To mend the network split, one side would have to concede and adopt the other sides rules.

Decreasing block size: About 1 in 20 blocks will exceed the limit enforced by the majority. Only nodes still using the old rules will accept the bigger block, all other nodes ignore it. The majority of the hashrate will quickly outpace the big block minority. Since the small blocks are acceptable to the old nodes, big block nodes will reorganize to the small block chain as soon as that chaintip has more total proof of work. Since the difficulty between chaintips can only differ across difficulty readjustments, this generally happens whenever the small block chain pulls ahead by one block in height. As the big block now becomes part of a stale chaintip, the miner that authored the big block loses their block reward. In result, whenever a short chainfork with big blocks occurs, the network converges back on the smaller chain eventually. The big block miners are losing money unless they adopt the rules of the majority, or force the split to become permanent (essentially hardforking from the softforked majority).


Which exchanges still support USD account-to-account (A2A) transfers? Now that Mt. Gox no longer offers MTG USD redeemable codes, what other exchanges offer these vouchers / redeemable codes / coupons?

Due to AML regulations, few exchanges offer this service which is typically considered a banking function.

http://en.bitcoin.it/wiki/A2A_Transfer_Methods

This functionality can be emulated at exchanges that have integrated a Ripple gateway.  BITSTAMP is one such exchange.


How do I find the txid and vout values for an input I want to spend? I was in the http://coinb.in/multisig/#newTransaction and wanted to make a input but it needed 2 values.

Txid, How do I get that?
TxIn/vout, Whats that and how do I get that?

If you want to send some coins, you have to have been given some coins before.

When someone sends coins to you, they make a new transaction. This transaction has a TxID (which is the double SHA256 hash of the raw transaction bytes) that everyone uses to refer to this transaction. A transaction can have multiple outputs, and each outputs allocates some of the previously unspent transaction outputs (UTXO) that were used as inputs in the new transaction.

So, really this question comes down to: what are bitcoins? Bitcoins are a pair of TxID and an index that uniquely specify an entry in the blockchain.

The developer documentation (https://bitcoin.org/en/developer-documentation) goes into great detail if you want to learn more.

As far as how do you actually get your hands on these values, you just have to have someone send you coins to your address (or mine them), and then you could just look your address up on a blockchain explorer and find any unspent outputs it has. From there, you can just use the web interface to see the txid and the output index. For example, I just grabbed a random transaction off from blockchain.info at https://blockchain.info/tx/86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7. You can see the txid is 86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7 and that there are two outputs (indices 0 and 1), the first of which has been spent, and the second one which has not been spent (at the time of writing).


BTC transfer duration When BTC is mined, it is sent to the BTC wallet. The duration of the transaction can be up to 24h for online wallets.
 Is the duration faster, when transferring BTC to a “cold wallet”?

Coins are spendable by a wallet as soon as the transaction is included in a mined block. Some online wallets use their own software to sync, or in other words, to make their application aware that the account has received coins. Applications that use this method could have varying durations for recognizing received coins. Furthermore, different wallet providers may also have additional criteria, such as requiring that at least 4 blocks have been mined after the transaction was included in a block. This is known as Minimum Confirmations. For example, Coinbase will credit your account once there have been 3 network confirmations. In this case, the duration to "receive" coins on a local wallet such as Bitcoin Core, would be much faster than on Coinbase, because you would not have to wait for 3 blocks in order to spend the coins. It's also worth noting that this is not an issue of "online" versus "cold" wallets, it's more of an issue of third-party service based wallets versus personal wallet clients which you control the keys for.

As @JBaczuk pointed out below in the comments, technically coins are spendable even without a confirmation. This is especially useful for child-pays-for-parent (CPFP) transactions, where the first transaction may have a fee that is too low, but it is used as an input in a second transaction with an extra high fee, so miners will include the second transaction, which would also require including the first transaction.


Why is a "first seen" rule is used to pick a side in a honest split, instead of deterministic criteria? I was just thinking, why nodes pick the first block they see when there is an honest split, instead of picking, for example, the one with the "best hash" (number further away from the difficulty cut)?

Deterministic criteria like that would allow the entire network to quickly know which block wins, and everybody would then build on top of that block. Much less hashpower would be wasted on the dead branch.

Unless there's some risk/problem in it I'm not seeing...

for example, the one with the "best hash" (number further away from the difficulty cut)?
Deterministic criteria like that would allow the entire network to quickly know which block wins, and everybody would then build on top of that block. Much less hashpower would be wasted on the dead branch.

If you see that you are very likely going to win on account of the deterministic criteria, whatever it is,  then you can withhold announcing your block while you attempt to form a successor and announce your prior win if you see a competing block show up. This would give you an advantage over other miners who behave honestly (and even if everyone does it, it would continue to give larger miners an advantage over smaller ones).


Can hackers behind the ransomware WannaCry be traced through bitcoin transactions? Can hackers behind the ransomware WannaCry be traced through bitcoin transactions? Is there is central server of Bitcoin where all transactions can be looked up from? And is it possible to identify hackers from IP address used to access their Bitcoin accounts?

Can hackers behind the ransomware WannaCry be traced through bitcoin
  transactions?

no, if they are smart enough

  Is there is central server of bitcoin

no

  where all transactions can be looked up from?

yes

  And is it possible to identify hackers from IP address used to access
  their bitcoin accounts?

no


Is OP_RETURN dangerous for Bitcoin? Please explain something about OP_RETURN to me?
https://bitcointalk.org/index.php?topic=1166928.0

I saw a discussion that the contents of OP_RETURN can open the value of access to the private key. I am not good at client scripting language. But I assume this is something related to the values of RawTX (R, S) where, when summing the additional value, you can calculate the value of X (that is, the private key). Am I right or wrong?

The method described in the post has nothing to to with OP_RETURN, but is concerned with the SIGOP limits in a block.

Each block has a limit on the number of SIGOPs that can be present in transactions in that block. Signature validation is a CPU intensive operation, and the limit exists to ensure that no block gets too big to validate on regular hardware.

The post describes how a single transaction can be made to consume up to 225 SIGOPS fairly trivially, limiting the number of such transactions in a block to 88. These utxos can be redeemed to any regular output, or an OP_RETURN.

Note that the post is from 2015, and the activation of segwit has increased the total SIGOPs allowed by a factor of 4, so this attack could cost more now.


Type and Amount of Transaction in Blockchain API I am building myself an alert program with which I want to send myself an alert via email if there are transactions ongoing at all (5) of my addresses.

I have chosen the Blockchain API because I couldn't find anything better for this.

How can I find out if this transaction is an incoming or outgoing transaction? This JSON below is one transaction from a few which i get return with the Request: https://blockchain.info/de/address/1MLnfxu3AicGcpBS4MbevCCQP8WSftkXj8?format=json

Also where can I find out how many BTCs are transferred in this one transaction.

FYI, I write a script in Python. I could parse all the 'value' values and add them together. Also i could check if my provided address, if it is in 'inputs' or in 'out'.

But isn't there a better way? Or are some better APIs out there for this?

{
   "ver":1,
   "inputs":[
      {
         "sequence":4294967295,
         "prev_out":{
            "spent":true,
            "tx_index":182562706,
            "type":0,
            "addr":"3NSHD5zB9wCMfoVXsuS9v8d6PcnKxDFKeg",
            "value":40000,
            "n":1,
            "script":"a914e3912957c315153f65bfef4322af64188ba7cdc487"
         },
         "script":"00473044022039d16bf80101ce331e93f8dd8d24e8770e3d7a8e367f2e54a86d2f4153ea5d99022048bff03a37f39180ac3b18d8619f6d450a4b3ec9ebf4bf24f598b16348187e550147304402203df2d77fefe694a5b58a1c77af3d73c75eab5bbe36fec3c1c7364fc7b9f4b367022048a80b164ada45a4b734586e6e6f2f3f624415287a346ef84bc3c6b63e67808f0147522102265981c8d731915bee94597c8f7fce92819ab37245b9c6b1f2f011015161adf02103c511b8fe3a5e60ad16bb14b0865f8a3f192ddb386c4f8d23f72edd24764e0e2352ae"
      },
      {
         "sequence":4294967295,
         "prev_out":{
            "spent":true,
            "tx_index":183105717,
            "type":0,
            "addr":"3NSHD5zB9wCMfoVXsuS9v8d6PcnKxDFKeg",
            "value":14980000,
            "n":0,
            "script":"a914e3912957c315153f65bfef4322af64188ba7cdc487"
         },
         "script":"0047304402202ec3a4c1bf1aa386f8db24e2ec0434f5224890ea9c510b067f03a39c1d69325a0220154ffb2d6f54875faa0ee2de10a78ace2fff30595a88732937e2827bddeab1ea01483045022100e8ee555d0cdf09a7803fbffdca4da3498393748f1ff52f10abfbfe6920bc118702202f7ffc9ff6289cfc17e26004298d6ce4379451fd3cb29399d7adf30e704dc10e0147522102265981c8d731915bee94597c8f7fce92819ab37245b9c6b1f2f011015161adf02103c511b8fe3a5e60ad16bb14b0865f8a3f192ddb386c4f8d23f72edd24764e0e2352ae"
      }
   ],
   "block_height":436110,
   "relayed_by":"176.126.247.116",
   "out":[
      {
         "spent":true,
         "tx_index":185011579,
         "type":0,
         "addr":"1PHdd9DpdHtxNeVeqkEbBu1pBoDcTws6kx",
         "value":5066000,
         "n":0,
         "script":"76a914f477fe7c4a0fce5dbc7c174ba2ab5d9ab27fe91d88ac"
      },
      {
         "spent":false,
         "tx_index":185011579,
         "type":0,
         "addr":"1MLnfxu3AicGcpBS4MbevCCQP8WSftkXj8",
         "value":9834000,
         "n":1,
         "script":"76a914df208b39050b2a3f1166216efda0855cc4df8aae88ac"
      },
      {
         "spent":false,
         "tx_index":185011579,
         "type":0,
         "addr":"3NSHD5zB9wCMfoVXsuS9v8d6PcnKxDFKeg",
         "value":60000,
         "n":2,
         "script":"a914e3912957c315153f65bfef4322af64188ba7cdc487"
      }
   ],
   "lock_time":0,
   "result":99980000,
   "size":627,
   "time":1477558874,
   "tx_index":185011579,
   "vin_sz":2,
   "hash":"1806396e0a7fa220d5626dae7ee4a5caa3b35d333f1885d25a440d256701bba4",
   "vout_sz":3
}

There is a better API, and it is the Bitcoin core API. You get all the data you require there. Blockchain.info must probably also be using the core API's (or they must have made a parser to parse the binary data of the blockchain on the machine running the full node). Using the core API's and the corresponding bindings present for various programming languages, you can access all the data from the blockchain you need.

There seems to be no txid field above but there's one tx_index which refers to that hex. You can get the number of BTC's in that transaction (input and output) by using the core api getrawtransaction(to access non-wallet transactions, you need to rebuild your blockchain after adding the line txindex=1 in the conf file and restarting the server with -reindex option)


Does one need to have a bitcoin wallet to buy/sell bitcoins? There appears to be so many exchanges / middle-mans on a bitcoin market (e.g coinjar.com) which can help to buy / sell bitcoin for a cut (usually 2-4%). Do they simply trade bitcoins using their own bitcoin wallet and just keep the client's balance of cash/bitcoins in their system?

They don't sell nor buy anything they are in the middle of a transaction. Check this out, Active buy orders are people who want to buy, and active sell orders are people who want to sell. The exchange is the place where all that people meet.

If you have Bitcoins and want to sell them for real money you have two options, you can sell it to the first buy order for the specified price and the transaction will be finished in that exact moment (if the buy order is for the exact or more amount of Bitcoins that you are selling) and you will be credited with real money that you can withdraw to your bank. Or you can set your own price and wait to see if someone wants to buy it for that price. Depending on the price you set it may take little time, longer or forever.

For every acount a wallet is created where you transfer your Bitcoins, real money is deposited in real banks and transfered to and from those banks.


Clarifications on hd multisig wallet I need clarification on multisig hd wallets. Let's imagine we have a 2/3 multisig. The first key is generated by the user on a mobile wallet, the second is kept on a server while the third is off-line (for emergencies). In an hd wallet the seed is generated from the seed phrase and, from this, the Master Private Key.

How does the generation of the other 2 Master Keys happen?

What do these keys share?

When new private keys are generated by the user are new keys derived also on the server?

HD is really about back-ups and wallet recovery, a multisig address can be created from any public keys regardless how/where they were generated. Heck you could use the same public key 3 times, although I wouldn't recommend it I'm just trying to prove a point.
To answer your exact questions:

How does the generation of the other 2 Master Keys happen?

Do you want 2 more master keys, or do you just think you need them? Additional master seeds are not necessary, but if you want more master keys then create additional HD seeds.

What do these keys share?

The master keys? They shouldn't share anything, again not relevant to creating a multisig address.

When new private keys are generated by the user are new keys derived
also on the server?

Private keys are not needed to create a multisig address, just the public keys. If you only want one HD seed to back-up, then use different accounts for each key pair. By accounts I'm referring to the derivation path, for example Account 1 Index 0: m/0/0/0/0, Account 2 Index 0: m/0/0/1/0, Account 3 Index 0: m/0/0/2/0, this would produce 3 key pairs, all with an index of 0 and the public key of each would be used to create the multisig address.


Calculate the hash of mined block using stratum parameters (coinb1, coinb2, xtranonce1...)? Miners get several parameters from the stratum pool: coinb1, coinb2, xtranonce1, xtranonce2... according to here.

I wonder if it is possible to reproduce the hash of one already mined block, but using that info and going all the way trough, and not just the merkle root from the block.

The only way I could think of is if, somehow, those parameters could be retrieved from the block. Since there are hashes involved to calculate the merkle root, I would say no... but I'm not sure, or maybe there is another way.

Thx!

When a pool gives a miner data to mine it is not data for one specific block, but a template for a block. The miner hashes many variations of this block data to try to find a block that has a hash value below the current target (which is determined by the current difficulty).

To calculate the hash of a block on the blockchain given only the data that the miner was given from the pool, you would have to do the same thing the miner did. You would have to hash many different blocks in search of that low hash - only then would you know the exact data the block contains - assuming you are not allowed to look at the block data on the blockchain.

For the old getwork protocol the pool would only allow you to set the nonce value in the block header. Everything else in the block was determined by the pool server. So you would have 4 bytes (32 bits) to search to rediscover the block someone mined with the given getwork-data. That's 2^32 (4294967296) different blocks. On average you'd have to search 50% before finding the right block. That's 2147483648 hash operations to perform on average. This is done in an instant with modern mining hardware.

With the Stratum protocol it gets worse. Stratum allows the miner to modify the nonce and a part of the coinbase transaction called "extra nonce 2", the size of which is determined by the pool, but usually 4 bytes. This means the miner has 8 bytes (64 bits) to fiddle with. That's a lot of blocks to search through. 2 to the power of 64. Though on average you'd only need to try 50% of those blocks.

It's actually a bit worse than the above because the miner may have also changed the timestamp on the block (ntime field of the block header). It would be a value close to the original timestamp though.

Usually pool servers push new work data to miners quite often. If you have equally fast hardware to that which found the block, then you should be able to do the above search in less than a minute. But that assumes that your miner and the one that found the block search the nonce and extranonce2 (and ntime) in the same way. For example if both miners start with a value of zero for nonce and extranonce2 and then increment from there, then it should not take long at all.


How to claim my BCH and BTG How to claim my BCH and BTG when my BTC is in Coinmotion and has been there when the forks happened? Coinmotion didn't and still doesn't support BCH and BTG.

In this case, you trusted Coinmotion during the hardfork and as you don't have the private keys, you can't really do anything. You need to hope that they'll accept BCH and BTG in the future on their site.

And their site says:

  The two options we plan to give our customers are as follows. When we are ready, each customer is presented with a choice.

  We can convert your BCH to BTC automatically and add the amount to your BTC balance.
      We can send the BCH to your own BCH wallet address outside Coinmotion.

  Our goal is to make BCH funds available in January 2018 at the latest.

https://coinmotion.com/blog/bcash-update/


The bitcoin-qt synchronization just stopped Someone recently stole the computer where my Bitcoin were. As my hard drive was entirely encrypted and as I had backups of my wallet.dat file in three different places, I'm not afraid of losing money, so that's not the problem here.

I bought a new computer, reinstalled everything including bitcoin-qt. I launched it and it started synchronizing with the blockchain. However, the sync process seems to have stopped, and hasn't moved since yesterday. When I put my mouse on the progression bar, it reads « Catching up… Processed 153771 of 264122 blocks [...] Last received block was generated 99 weeks ago. [...] », and it does not change. That's strange, because on the bottom-right corner, it reads that I have « 8 active connexions to Bitcoin network ».

Has anyone an idea of what the problem could be? I doubt that it is a connexion problem, because it first worked perfectly… I would prefer to make bitcoin-qt work rather than use another client.

You can try downloading bootstrap.dat from the torrent at sourceforge as suggested in the answer to Is there a newer Bitcoin blockchain download available?

Because of its format, the client will verify the integrity and the bottleneck will switch from your download speed to your CPU speed.

This is the link to the torrent file