text:
Can I create a private bitcoin network?
Say if I was creating a new bitcoin website and I want to transfer some bitcoins from one of my own private wallets to another would that make it so the transaction would confirm almost instantly because it is a closed loop?

Yes you're talking about an off-chain solution. Exchanges use this solution.
It would be prohibitively expensive and impractical to transfer ownership on-chain for small amounts and/or frequent changes, so you send your coins to a single wallet owned by the exchange.
The exchange has their own system to keep track of who owns what. This system is private and not transparent, but fast and potentially free. Then when you choose to send it from the exchange to your wallet, a network fee is incurred at that point.
The off-chain solution could also be a blockchain solution, though not distributed as no one else would have any interest in maintaining your businesses ledger.
e.g. with coinbase.com
The Deposit:
Your wallet -> "your" coinbase wallet
  occurs on main net blockchain
  network fees incurred
  technically deposited into a single main net wallet
  wallet controlled by coinbase
  you trust them with your coins at this point

Interwallet transfer on coinbase:
"your" coinbase wallet -> another wallet on coinbase of "your"s
  occurs off the chain
    as such it's free
    as such is opaque
  could be implemented however coinbase sees fit:
    vb running in an excelsheet for all I know!

Withdrawal:
"your" coinbase wallet -> Your wallet
  occurs on main net blockchain
  coinbases single wallet is paying you
  network fees incurred
  grouped with other withdrawals for network fee efficiency
  coins in your full control again

So is there only one big network every website like coinbase.com and blockchain.info use. They don't have their own networks for internal bitcoin transactions where speed is a priority?

Yes, they have their own. That's what I am saying "The exchange has their own system to keep track of who owns what."

but coinbase.com yes, blockchain.info no - that runs on-chain and is not an exchange.

And if I was running my version of coinbase where getting the bitcoin transaction confirmed from one of my own wallets to another one of my wallets in under 1 second is at the highest priority I could run my own network where internal transaction are confirmed in very little time?

Have added an example.


text:
why bitcoin escrow don't use fiat currency?
Cryptocurrency escrow,  like localbitcoins.com, use bitcoins as guaranty funds.
Seller transfer bitcoins to merchant as guaranty, later when buyer has paid with fiat money to seller, merchant make the transfer of bitcoins to buyer wallet.
why bitcoin escrow use bitcoins guarantee and  don't use fiat currency?

I think it's because bitcoin transactions are more transparent and it's always possible for third parties to verify the escrow is behaving correctly.

Because it is much harder to do escrow with fiat.
Fiat currencies are subject to various regulations which make this difficult. The escrow service would have to be registered as a money transferring business and be required to follow AML/KYC regulations. This means that all users would have to submit personally identifying documentation to the service in order to do any trades.
Additionally, there are multiple ways that fiat can be transferred. If you look on LocalBitcoins' website, you will see that you can do a variety of things for transferring the fiat; you can send cash by mail, cash in person, you can do bank account transfers, you can purchase goods for the seller, etc. There are a lot of different ways to send the fiat to the other person. If they put the fiat in escrow, then they would be limiting the number of ways that the fiat could be transferred. Conversely, there is only one way to transfer Bitcoin.
Furthermore, doing a fiat escrow would mean that the service is subject to whoever they are using as their bank. The service itself cannot actually hold the fiat money when it comes to things like bank and wire transfers (or it's really difficult). Rather they have to have an account with a bank and the money would go into that bank account and leave from that bank account. This introduces another third party who is not necessarily trusted. That bank could shut down the service's bank account thus causing all users whose funds are in escrow to lose all of their funds. It would, in general, introduce more risk to trading.
Lastly, the idea of services like LocalBitcoins is centered around the idea of trading Bitcoin for physical cash, typically in person. This means that it is extremely difficult to provide escrow services because someone from LocalBitcoins would have to be physically present for each trade to hold the fiat while the Bitcoin transfers. That would simply be unfeasible and impractical to do. However, because Bitcoin is a digital asset, the Bitcoin can easily be held in escrow on their servers and the trade can go along as long as both parties have internet access. This is much easier and cheaper to do.
Thus Bitcoin is easier to do escrow with than fiat, so such services escrow the Bitcoin rather than the fiat.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
is it okay to disconnect Antminer like S7 >
I have a kind of unstable internet connection
sometimes it gets disconnected for over an hour
the question here is , does that hour of mining without internet count ?
thanks

While you aren't connected to the internet you can't submit shares to your pool, so you won't earn anything during that time period. That's why it's recommended for miners to have fast, low latency connections.

No, while mining it should stay online.
If it gets disconnected, then you don't need to do anything, it'll connect once the internet is back up.

and what about the time it was mining without internet ? was it just working and consuming power without any benefit ? or it will upload the mined coinz  when it gets connected ? thank thank you

It won't mine, it'll just check whether internet connection came back.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
blockchain.info api (Balance Updates [POST]) confirmations not received
I'm trying to use "Balance Updates [POST] Monitor addresses for received and spent payments" from https://blockchain.info/api/api_receive
I subscribe to an address and get the response:
{
  "id": 15108,
  "addr": "1P9RQEr2XeE3PEb44ZE35sfZRRW1JHU8qx",
  "op": "ALL",
  "confs": 3,
  "callback": "https://d83bb66d.ngrok.io/bitcoin/confirmations",
  "onNotification": "DELETE"
}

then with each new transaction I get a notification with 0 confirmations, that looks like this:
{
   "address" : "1P9RQEr2XeE3PEb44ZE35sfZRRW1JHU8qx",
   "confirmations" : 0,
   "transaction_hash" : "38dbb8083a8c3006eae6c1194789941943cb60201ebfb03963188d4eb1d01d23",
   "value" : -9030800
 }

but I never get a notification with the 3rd confirmation

confs - Optional (Default 3). The number of confirmations the transaction needs to have before a notification is sent.

I tried setting confs to 1, 2 and leaving it as default, but I never get any confirmations, I have tried with different addresses, right now the transaction in this message has 5 confirmations but I didn't get any notification.
https://btc.com/38dbb8083a8c3006eae6c1194789941943cb60201ebfb03963188d4eb1d01d23
does any one know what's wrong ?
thanks

You need to set onNotification to KEEP, otherwise all future notifications such as those for confirmation number will not be sent.
From the docs:

You are required to specify the request's notification behaviour. Setting the behaviour to 'DELETE' will delete the request after the first relelvant notification is sent to your callback address. Setting the behaviour to 'KEEP' will send additional notifications every time a transaction with the specified confirmations and operation type is sent to or from the address in the request.

Thanks for answering. Yes the documentation says after the first relevant notification, in the default case would be when a transaction gets 3 confirmations and that never happens, I don't get any confirmation. I also tried setting it to keep, but got the same behavior

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
rewriting past transactions in Bitcoin
Is it possible to rewrite past transactions in Bitcoin?
For example, lets say, we have a super computer with any desirable speed, that would be able to calculate hash as fast as we want. Would it be possible to take for such computer, a block that is 2 weeks old from now and create (from that block) a new chain that is bigger than today's chain with its own transactions? If so, the current network would accept our new (forged) chain and all the past transactions would become invalid.

Is it possible to rewrite past transactions in Bitcoin?

Yes. If you have more than half of the hashpower, you can eventually rewrite a chain of any length.

For example, lets say, we have a super computer with any desirable speed

Cryptography is based around protecting against adversaries with finite computing power. As soon as you suppose that you're going up against someone with infinite computing power, there's no public key cryptography system that you can use, because your adversary can just try every possible private key.
It's kind of like asking, "How do banks protect against thieves that teleport money out of safes?"

If so, the current network would accept our new (forged) chain and all the past transactions would become invalid.

Yep.

Then you make the deal with the government to destroy bitcoin.

I don't really see why the government would care if people used Bitcoin. Given that there are really trivial things they could do to make it very difficult to exchange or use Bitcoin, which they are not doing, I doubt they care.

Is it possible to rewrite past transactions in Bitcoin?

Yes. That is one of the reasons it is recommend to wait for more than one confirmation before accepting a bitcoin transaction.

For example, lets say, we have a super computer with any desirable speed, that would be able to calculate hash as fast as we want. Would it be possible to take for such computer, a block that is 2 weeks old from now and create (from that block) a new chain that is bigger than today's chain with its own transactions?

No, since such a computer is itself impossible.

If so, the current network would accept our new (forged) chain and all the past transactions would become invalid.

The question is, as I said, based on an impossible premise. Here are some further obstacles:
1) You can't just invent an arbitrary amount of computing power. There is only so much physical space accessible to mankind. There is only so much energy available.
2) A supercomputer is entirely the wrong tool since supercomputers are general purpose devices. They're absolutely atrocious at attempting to rewrite bitcoin transactions. Honest miners with specialized equipment would have a huge advantage.
3) So say instead of a supercomputer, you spent a billion dollars to build a device specifically to do this. You would be able to do this exactly once. The community would react by either changing the mining algorithm or other means that produce the same effect. So you would get this one attack and then you would have a billion dollar paperweight.
4) Even if you thought that was all worth it to shake confidence in bitcoin, it would likely backfire. What would happen is that bitcoin will have recovered from your billion dollar attack, you'd be out a billion dollars, and bitcoin would still keep going.

Here is an example how you can hack Bitcoin. You create a company that makes FPGAs, then you manufacture all the FPGAs by the amount of much higher computing power than Bitcoin's network. Then you make the deal with the government to destroy bitcoin. They pay you for the attack. You use those devices to rewrite the blockchain to steal the money out of bitcoin and then you sell those FPGAs like you would normally do to regular users. Instead of losing money you are making more. So, a supercomputer faster than Bitcoin's network is completely real. You are making dangerous assumptions.

@Nulik Except you can't use FPGAs to attack bitcoin anymore -- FPGAs are also general purpose devices. And read 3 and 4 -- it wouldn't destroy bitcoin.


text:
How do I send Bitcoin from my cold wallet to a new one?
I have the public/private keys for my cold wallet. I want to move it all into an Electrum wallet. I understand that I should send my entire balance at once. What medium should I use to make this transfer? I do not want to use Mycelium or any phone based wallet.
Side question: If I want to be able to spend small amounts of Bitcoin on purchases what is the ideal wallet setup I should be using?

You should avoid asking several questions in one post

Funds from a cold wallet need to either be imported or swept (for cybersecurity reasons sweeping is always preferred over importing) into most any hot or warm wallet to then sent to another cold wallet address synthesized from private keys that are usually in either the Wallet Import Format (WIF) or in BIP 38 standard format (is AES encrypted and starts with the letters 6P). Wallet imports or sweeps usually take WIF or BIP 38 input formats that have associated input error checking versus raw hexadecimal that a prone to human input errors like Ethereum.
Electrum is not technically a cold wallet unless the Electrum BIP 39 seed words have never been loaded into an Electrum warm wallet.  An Electrum wallet is warm only if it uses a hardware wallet such as a Trezor, Ledger or Keepkey token generators that have been loaded with BIP 39 seed words. Otherwise, the Electrum wallet is a hot wallet.
Cold wallets need the private keys and associated public addresses generated on a trusted offline computer. Cold wallets can use self contained JavaScript programs, or a standalone binary executable such as Bitcoin-Explorer (bx) running on air gapped computers that can also leverage brainwallets provided the brainwallets input text have sufficient entropy.
To answer your side question, you should be using a HD hardware token generator with Electrum to have warm wallet functionality, or you need to use multiple cold wallets probably using a trusted JavaScript key generator program, not a single cold wallet.


text:
Insight API: txs json shows only 10 tx?
I have an Insight API Server running, it's fully synced and working. I would like to get a json to receive every tx within a block.
On https://github.com/bitpay/insight-api it says I have to use:
Transactions by Block
  /insight-api/txs/?block=HASH
  /insight-api/txs/?block=00000000fa6cf7367e50ad14eb0ca4737131f256fc4c5841fd3c3f140140e6b6

For example we take block #301453. This block has 725 transactions.
https://insight.bitpay.com/block/00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958
If I use the api to get the json file with this link:
http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958

... then it shows the first 10 transactions only (numbers 0 - 9). But there are 725 tx in this block.
It looks like the number 10 are those addresses are the first who are displayed. If i scroll further down, more transactions appear. But why does the json request only show 10 txs?
How can I get ALL transactions in this block - as the documentations mentions?

You have two options.
Option 1:
The returned json includes a "pageTotal":'some number'.
You can create a for-loop to loop through all the pages with API calls.
Let assume there are two pages aka "pageTotal":2
To fetch the first page, append parameter [&pageNum=0] to the end
Example usage:

http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958&pageNum=0

To fetch the second page, add param [&pageNum=1]
Example usage:

http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958&pageNum=1

Option 2:
Modify transactions.js , 'var pageLength' on Line 253.
The default is 'var pageLength = 10;'
Unsure if there are consequences by doing this, but I assume it should be fine.

Thanks! I changed "var pageLength" to 50000. This should list 50.000 tx and should last a while. :) I think option two is the faster solution.


text:
Verify paper wallets
I generated a paper wallets with offlineaddress.com. Is there a way to check if the private key corresponds to the public key without compromising the wallet by loading it onto an online computer?

See also this question.

First off, only trust highly-reputable software to generate private keys, especially if they're web-based. It seems like this software has only 16 stars on GitHub and only 2 contributors: https://github.com/mikewoods/OfflineAddress.com
To answer your question, the only way to verify that a private key corresponds to the public key is to actually run the algorithm on a computer. My best advice here is to use a computer that is offline and that boots a highly-reputable open source operating system.

Yes, the addresses have been created with OfflineAddress.com with a live Ubuntu. So import the wallet (on a live system) and see if the private key computes to the public key? Or trust OfflineAddress and safe the hassle?

Import the private keys into electrum, it will generate the public address to double-check.

To clarify, reconsider using this service as it's the first I heard of it myself. Even "reputable" services like vanitygen have been compromised such that priv keys are stolen.


text:
Problem receiving - confirmations stuck?
I have tried to transfer some btc being a first time user from one wallet to another (both online version). It seems the btc was sent but the receiving wallet is still showing '0' 24 hours later.
Receiving wallet does require three confirmations for funds to show but from what I have been able to find on blockchain it should have passed this point! Being a newbie I'm obviously concerned if everything is as it should be!
This is the transaction for the sending wallet, it seems to show the funds transferring in and then out:
https://blockchain.info/address/1BkJ16RfYTcPbhsdWKyKkg2pNVZKjbyfTA
This is the transactions list for the receiving wallet which currently shows '0' balance:
https://blockchain.info/address/1BkKpkHVcxoQEjGxZtHaxVPX9xuVh8ru5i
It shows the transactions as 4 so am concerned all is not right! Any advice is greatly received!
Thanks

I am unsure what your issue is, it seems that the receiving address you provided is working fine and is sending transactions within ~5 minutes of receiving them. If your problem is unresolved, could you please elaborate: what wallets you are using and what the desired effect would be.

authors: Юлия Кошелева


text:
bitcored + vmware: disk space increases INCREDIBLY fast
I installed ubuntu-16.04.3-desktop-amd64 within a vm maschine from vmware. After downlading and installing bitcored (I did these steps: https://bitcore.io/guides/full-node) the blockchain starts to syncronize but keeps adding disk space incredibly fast.
Insight says the blockchain is 1 % synced and already takes 30gb+ (I just installed ubuntu and there is nothing more on this system). Maybe this is some error with cache/temp not beeing deleted after progressing a block or something?
If I let it run it creates 400gb+ until the virtual maschine crashes. After that, vmware is not able to start the vm again. (current bitcoin blockchain is <200 gb. I dont know why this thing needs to write 400gb+ of data to my disk space).
Opening "disks" on ubuntu says the system uses ~13gb (which should be right). Where does the other endless GB come from?
Any help is highly appeciated!

It may be because of the nature of the entire blockchain, and the virtual disks itself. 400Gb+ can be the blockchain obtained from the network, temporally persisted, and 13Gb seems to be the amount that is really persisted.
Those numbers are fine in orders of magnitude when operating a full bitcoin node. To control the grow of the space, maybe creating a fixed-size virtualbox will help

Looks like it was an vmware issue. Seems to work fine with virtual box. Thanks! :)


text:
How important is Graphics Ram for hashing
Some altcoins are designed to be "memory intensive" to avoid use of ASICs to mine them.
Does the RAM refered to here, mean the RAM of the computer or the RAM on the GFX card itself.
When looking at passmark these two GFX cards get almost the same score 8687 vs 8773:
GTX 1060 (3GB) vs GTX 1060 (6GB) comparison on passmark
For gaming the ram can be important for having high-resolution textures in ram. But how much does it matter for hashing memory intensive hashes?


text:
What was the bug for the Bitcoin value overflow in 2010?
In 2010, there was an incident of value overflow on Bitcoin.
I am not a developer, but I want to know what the bug was in more detail. #1 is the only answer I found online, and #2-3 are my attempts to alternative answers.
1.
Source: https://bitfalls.com/2018/01/14/curious-case-184-billion-bitcoin/
Total outputs were greater than 184,467,440,737.09551615, the maximum number that could be stored, by 50.51. And 50.51 was equal to the input value, so the tx was processed.
This was the tx, according to the source.

from my address which has 50.51 BTC
send 92233720368.54277039 to address A
send 92233720368.54277039 to address B
send 50.51 BTC to address C

But I am not sure. Looking at the block on jgarzik's original post, it looks like 50.51 was a separate tx from the two 92233720368.54277039 txs. And the input value for those 2 large txs seems to be 0.5. It doesn't really make sense. So, here are my alternative possible answers.
2.
The combined outputs of two large txs, 184,467,440,737(decimals cut off for simplicity), is subtracted from the input of 0.5, which results in -184,467,440,736.5. But because the variable was an unsigned number, it was wrapped (around the max number of 184,467,440,737.09551615) to end up as 0.5 (or smaller). This is equal to the input value, so the tx is included.
3.
Similar to #1, but I saw somewhere that negative sign could erroneously be interpreted as another number digit. So (rather than wrapped around the max number) -184,467,440,736.5 is seen as a larger positive number. I don't know what number it will become. 1,000,000,000,000 + 184,467,440,736.5? Or 2 x 184,467,440,736.5?
Maybe something else? Please let me know what you think really happened. Thank you in advance.

Does this answer your question? What’s the purpose of checking for input overflow?

I am afraid not. But it's interesting. Thanks. @user2284570

Your first source is wrong.
The block in question contained three transactions: the first is a coinbase transaction, the second is the one that did the overflow. The third is unknown, and not relevant.
The overflow transaction does not spend from the first transaction, rather it spends a UTXO that was created in an earlier transaction, which is actually in the blockchain and can be looked up today. The UTXO it spends is 0.5 BTC.
The two outputs of the overflow transaction are each 92233720368.54277039 whose bytes are 7ffffffffff863af in hex. The most significant bit of this number is the sign bit - if it is 1 then the number is negative, 0 it is positive. In this case, these values are positive. This allows these values to pass the check that the output values are not negative.
The next relevant check is that the amount in the inputs can provide for the amount in the outputs. However the way this was done was not by checking the values directly, but rather the fee was calculated (input amounts - output amounts), and the fee is checked to be non-negative.
But because the output values are so large, when they are added together, they overflow the maximum signed integer and become negative. Subtracting this sum from the 0.5 BTC input becomes an addition as subtracting a negative number is addition. So the calculated fee is greater than 0 and this last check passes.
There are two inflationary effects of this bug. The first is the obvious one of the two extremely large outputs. The second is the transaction fee. The miner of that block can collect the miscalculated transaction fee of the overflow transaction, and so there is an additional 0.00997538 Bitcoin created.

Thank you for your answer. Please see the following and let me know if I got it right.

A 64 bit signed number can have from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.

Translating them from Satoshi to Bitcoin, -92.233,720,368.5477... to 92.233,720,368.5477...

The sum of the two output values, 184,467,440,737.0850, is expressed as -0.01, by overflowing the max positive number.

Subtract it from the input value of 0.5, and you get 0.51.

As this is positive, the tx is processed.

Another minor question, lest I forget, is about the coinbase tx. It had 50.51000000 as the output. How is it larger than 50, the mining reward? Is the tx fee included here? If so, why is it slightly larger than the (though erroneous) difference of in and out of 0.00997538?

The coinbase outputs include the transaction fee from both the other two transactions in the block.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What are concrete uses of Bitcoin script?
I am looking at solutions to simplify the architecture of Bitcoin from a more theoretical perspective. I am thinking about removing Bitcoin script, however I am not sure what restrictions this introduces.
I find many vague arguments, that having script makes us more flexible, however I am looking for concrete examples.
I have the following things:

Payment channels
Gambling / distributed random generator
Storing data in the blockchain / Proof of publication

What else is out there?

Are you thinking of using the P2PKH as the only way of sending transactions? (Just to clarify what examples can be suggested)

I'm wondering whether your underlying question is: "What are the advantages of having a script language for transactions instead of a more simple transaction format?" Perhaps you would like to edit your question to specify your question more clearly and to tell us a bit more about what we would be comparing to.

multisig transactions
blockchain-embedded escrow
time-bound transactions
proof-of-burn
bets based on some oracle, either trusted or decentralized

I suppose there are many more and that some if not all of the above can be, more or less efficiently, realized with P2PKH, possibly with some extra protocols required.

You can go through the following links:
https://www.coursera.org/learn/cryptocurrency/lecture/HWjti/bitcoin-scripts
and https://www.coursera.org/learn/cryptocurrency/lecture/Vu5eX/applications-of-bitcoin-scripts
to know more detailed examples of the importance of Bitcoin scripts.


text:
How do you get the OP_HASH160 value from a bitcoin address?
I'm trying to sign a coinbase transaction. I know I need to use 76 A9 14 (HASH160) 88 AC but I don't understand how to create the HASH160 (20 byte) from a bitcoin address.

Check the Wiki. I think what you are looking for is point 3:

How to create Bitcoin Address
0 - Having a private ECDSA key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
1 - Take the corresponding public key generated with it (65 bytes, 1
  byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes
  corresponding to Y coordinate)
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
2 - Perform SHA-256 hashing on the public key
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
3 - Perform RIPEMD-160 hashing on the result of SHA-256
010966776006953D5567439E5E39F86A0D273BEE
4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main
  Network)
00010966776006953D5567439E5E39F86A0D273BEE
5 - Perform SHA-256 hash on the extended RIPEMD-160 result
445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094
6 - Perform SHA-256 hash on the result of the previous SHA-256 hash
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30
7 - Take the first 4 bytes of the second SHA-256 hash. This is the
  address checksum
D61967F6
8 - Add the 4 checksum bytes from point 7 at the end of extended
  RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin
  Address.
00010966776006953D5567439E5E39F86A0D273BEED61967F6
9 - Convert the result from a byte string into a base58 string using
  Base58Check encoding. This is the most commonly used Bitcoin Address
  format
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

You can check your calculations against my testing suite.

Thanks! Unfortunately, point 0 is where I get lost... Does calculating the hash require access to the private key? Can I sign a coinbase transaction using a bitcoin address bypassing the need to calculate the HASH160?

@user789235 If you want to SPEND the transaction, you need a private key. If you want to specify the recipient of the transaction, you only need to put the address in and some ops. Read here for more info https://en.bitcoin.it/wiki/Script#Scripts

Thank you. I'm pretty sure I get it. So, I now want to create a signature of a testnet coinbase transaction. Is there an easier way to get the hash than starting with generating a public/private key pair from scratch?

@user789235 If you just want to create a coinbase transaction that credits a given address their coins, you just specify the public key or address in the output script. If you want to create a transaction that spends the coinbase input, I have no idea how to do that.

Could you incorporate part of the info from the wiki in your answer so that the answer is not dependant on "point 3" on the wiki staying the same. Thanks!

@D.H. Thanks for the suggestion, edited accordingly.

Please can you explain the steps for me and I appreciate help

@ThePiachu: The OP asked about the opposite process from what you described. You're describing how to go from the private key all the way to the address. He's asking how to get from the address to the pubkeyhash - that is, undoing step 9. Of course, I only know what he asked, not what he wants to know.

This wiki page is probably more helpful.  It describes how the bitcoin address is created from the 160 bit hash.  You need to run those steps backwards to get back to the 160 bit hash.
For example, if your address is 1HgiEYL6fsKrfh8wuMhAGfvSc6PY5ZXJdv, you first count and remove the 1's from the start.  There's only one '1' in most addresses.  Remember this for later.
With the rest of the address, use this page to convert each character into its base58 value:  'H' -> 16, 'g' -> 39, 'i' -> 41, ..., 'v' -> 53 etc.  So you have a list of values: [16, 39, 41, ..., 53].
Then combine all these values into a single large number:
(([...](((16) * 58 + 39) * 58 + 41) ...) * 58 + 53)

Convert the single large number into a sequence of bytes, prepend the same number of 00 bytes as the number of '1's you initially removed from the address, remove the last 4 bytes (that's the checksum), remove the first zero byte (that's the version byte), and there's your 160 bit hash.

Perfect! I'll start the calculation. As a lazy mathematician's way of getting what I'm looking for, I came up with this approach. I'm not sure it's valid, but I send 20btc on testnet to the address for which I wanted a HASH160. That transaction is here I think I can use the hash from this transaction. But I'll do the math to confirm....

I don't think the testnet client will accept a regular bitcoin address as being valid.  Maybe I've misunderstood what you did.

For regular addresses you can use the addresstohash tool in blockexplorer.
For testnet addresses you can open https://blockexplorer.com/testnet/address/the address you want and read the Hash160 field. This works for addresses which aren't in the block chain too.

Thanks. This was the easy answer I need for my one off test!

You can use Casascius address utility to do various manipulations with keys, hashes and addresses.


text:
What the maximum number of txout in a transaction?
I know the maximum transaction size is 500Kb.
I also know there is a maximum for sigop in a transaction (20,000?).
What I'm interested in is what is the maximum number of txouts you could include in a single transaction.

There is no practical maximum number of outputs in a transaction. The number of transactions can be up to 264-1, or 18446744073709551615. The transaction fee would be more than the total bitcoins to ever exist.

The maximum block size is 250,000 bytes (https://en.bitcoin.it/wiki/Transaction_fees).  txin is approximately 148 bytes, a txout is about 34 bytes. Assuming 1 txin then max_txout ~= 7348. However, I believe that calculation is also limited by the max sigop limit.

@GeorgeKimionis: The number of transactions is stored in the Bitcoin block as a Variable length integer, which has a maximum range of 2^64-1.


text:
Recommended Transaction Size
I know the maximum transaction size for a BLOCK is 250,000 bytes. My question is a little different.
What is a recommended transaction size for best selection of the transaction by pools? For example say I have 500,000 bytes of transaction to send over the network. How should I chunk those transactions? 50,000 byte transactions? 10,000 byte transactions?

If you are trying to minimize your expenses from sending transaction, consider this bit from https://en.bitcoin.it/wiki/Transaction_fees
Sending
A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction.
Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).
Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.

It's not about size, it's about fee. If you can have a high enough fee to make a massively sized transaction be incentived to miners, your good. See transaction priority for what I mean.

I understand what you are saying about fees... Perhaps I'm over thinking it. My assumption is that large transactions might have a harder time getting included in a block because the block may be filled with a number of smaller transactions. Thus, there should be an equilibrium point where over that point (this is the point I'm trying to ascertain) it becomes harder to include large transaction in a block


text:
Createrawtransaction questions
I'm in the process of assembling raw transactions and I have a couple of questions.
I'm using listunspent to get a list of the transactions I can spend....
First, should I select the oldest transaction first for inclusion? Or is there a better way to select transactions?
Second, for calculating the transaction fee, is there an easy way to estimate the size of a transaction? For example, can I say each output is X bytes and each input is Y bytes?

You don't have to select the oldest transactions, they are same as the recent transactions in blockchain's utxo view. When building a transaction, you can take the transaction size into consideration, which could affect the transaction fee.
Generally, each output is 148bytes and each input is 34bytes. Here is a more accurate way to calculate transaction fee.
How to calculate transaction size before sending


text:
Bitcoin-qt falls behind on blockchain, how to replace?
On Apple Mac, bitcoin-qt is 14 days behind. Never approaches current time. Have downloaded current blockchain from trusted source. Where to install? What procedure?

Has it stopped downloading entirely (even after leaving it on for several hours), or does it just lag behind?

Will never catch up. For 2 weeks was behind 7-9 days, then 11 days just last week, and now 14 days behind.

My question is: does it still make progress? Are blocks (very slowly) coming in, or not?

I know that there is a torrent where you can download the blockchain to jumpstart your fresh installation. This should also help to update your local wallet. In order to download and import the blockchain manually have a look at the instructions and the download link in this bitcointalk thread:
https://bitcointalk.org/index.php?topic=145386.0


text:
Synchronising official bitcoin wallet for the first time; at 95% started going backwards
I.E. 9900 blocks remaining, 9904 blocks remaining and the total percent synced is decreasing. Is this normal behaviour? I'm on a mobile broadband connection but http connections are working just fine. It also says I have 8 active connections which I understand to be the maximum?
Thanks.

The number of blocks remaining is only an estimate, based on what other nodes say. There are maximum 8 outgoing connections, so if you can't receive any of your own, 8 is all you'll see, but that's plenty for synchronizing. Just wait somewhat longer.

@PieterWuille Thanks. Just in case this helps anyone a quick reboot has remedied the issue and it is no progressing as one would expect.

Note that downloading the blockchain will greatly speed up the syncronisation process: http://bitcoin.stackexchange.com/questions/799/can-i-download-the-whole-block-chain-from-somewhere

Looks like you were just unlucky in choosing your peers.
When connecting to a peer your client and the peer exchange a handshake message. Part of this handshake message is the height of the longest chain the peer has locally stored. Your client will then starting to download blocks until it catches up to the top of the longest chain. If the peers you connect to happen to be also catching up with the chain you will only see the length of their chains and will be unaware about the real length of the longest chain in the entire network.
Nothing to worry about, you will eventually have an accurate estimate of the real length: as soon as you connect to a peer with the longest chain, or one of your peers has caught up to the longest chain, your client will update its estimate.
Reconnecting also works as new peers are chosen. When you wrote your question, on October 24th, the longest chain was 204'663 blocks long, so the ~10'000 blocks or so were quite a long way off. Hopefully by now you caught up to the head of the Blockchain.


text:
Any advantages in terms of our location & East-West timing differences for self mining on a 100 th/s btc rig
I do live in india.. I believe that bitcoin mining rig owners are very lessaound us ..I read some where that  we will be able to mine more bitcoins  while the west or far-east  sleeps..

What you read is not accurate.  There is no significant difference in mining performance depending on your location.
First of all, as far as I know, the vast majority of miners run their equipment 24 hours a day (since leaving them idle just wastes the investment in hardware), so time zone differences are irrelevant.
Also, to first order, your chances of mining a Bitcoin block depend only on your hash rate and the network difficulty; it makes no difference what other miners are doing at that moment.  So even if the rest of the world quit mining completely for several hours, it wouldn't help you at all.
Of course, the network difficulty is determined indirectly by how much mining is being done around the world, but the difficulty is adjusted only once every 14 days or so (2016 blocks), so variations over the course of a day would average out.
There is actually a very slight disadvantage in being in a part of the world that has relatively few miners.  Suppose, for example, that most miners are in New York and a few are in Bombay.  If New York-based Miner A finds a block (say at height 12345) and announces it on the network, New York miners will know about it quickly, while it will take a few tens or hundreds of milliseconds to propagate across the Internet to Bombay.  During this short time, Bombay miners are at a disadvantage.  If Miner B in New York and Miner C in Bombay both find blocks during this window, B's will be linked back to A's block, whereas C's will be linked to the block before A's.  Thus B's block is part of the longer chain and will be accepted by the network, while C's will be orphaned.     But since this window would be less than a second for each block, which happens roughly every 10 minutes (600 seconds) on average, the disadavantage is at most a couple tenths of a percent.
The most important way that your location would impact your mining profitability is your local cost for electricity.


text:
How to export bitcoinj wallet
I am working on an app which uses bitcoinj. I want to implement export/import functionality to a standard format which can be shared with as many as possible wallet apps.
Is there a standard format used by wallet apps?

Well exporting the raw keys is as standard as you'll get. Different wallet implement their own file format for storing information such as addresses, and keys. But most wallet have at least an "import private key" functionality so that would work.

authors: Кирилл Самошкин


text:
Mining Block header bit reversing
While trying to understand the mining process and checking in python..... i am puzzled with which info from/to pool are in Little Endian, which one needs reversing in building the block header + hashing and which one not. ??
For example ... Let's start with connecting to solo.ckpool.org
response to mining.authorize gives me ..... job_id,prevhash,coinb1,coinb2,merkle_branch,version,nbits,ntime,clean_jobs =
{'id': None, 'method': 'mining.notify', 'params': ['59bc8dfc0000029f',
        '0eba48f47bc0ab4bb35b230849868bf1d79aeb19006eed460000000000000000',
        '01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff35039a6807000404d5bc5904fc873d140c',
        '0a636b706f6f6c112f736f6c6f2e636b706f6f6c2e6f72672fffffffff03c4626c4e000000001976a914fc6123f4bfd3a840b4387ab90e9801e98fb17cf888acb1caca00000000001976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac0000000000000000266a24aa21a9edab3b87f3963e55a23f3cea5e4435bf6637328fd5e329bb8fdac7d31c3a01d26200000000',
        ['c251d18568d2cdb07c376d5f3304a2161e3d09d289d1a7e53737199171d73ae6',
         '4f9bcac3ec00fc8238db04b7758a1b673bdf38b93e48159678b60b51517dd563',
         '2aadad2c9c8e6df5c71264524b090cdf89830f12949527f7872c243bc1dc552c',
         '8c5edf39c0d85c9853308eef3ce6f9b71c8d6584ca4120d411bc75987bb2f254',
         '48751c2ae0ddc05f5d504a3d6039e7d5afb3d5f2a6aaac93bd5822e5f8efc328',
         '3e9b5c6b986c2ddc09bf8604eb2bd2a3b49b46f11042c282331a206dadb4296e',
         'c65f502b11b325abc0fac847e8fc5cd300169160e7244b29dd5acc3d0e4b8605',
         'afe7d2287020c4291f609a772adbeafc952a8de0ced38a7346acb6c7103bec6d',
         '0caa545ae63de39d47baea100ea15a18061235d7e1a372fbca88edf9ca5ac797',
         'c5bfff15b4dd64e7faac98f1bba118fb11990e4ff146cb45c7f4af6b93e2ea03',
         'a8805201e8152c1f5835c9aa024752fb34aeb7fa55dd3af0ae6109918f328dbb'],
        '20000000',
        '1801310b',
        '59bcd504',
        True]}

Based on the pool response....I can build the coinbase just by
coinbase = coinb1 + extranonce1 + extranonce2 + coinb2
coinbase_hash_bin = hashlib.sha256(hashlib.sha256(binascii.unhexlify(coinbase)).digest()).digest()

and same to include in merkle tree with hashing to get merkle_root. I am not sure if i need to reverse the bits here ?
But to build a block header ... should i do this..
header = version + prevhash + merkle_root + ntime + nbits + nonce

or this..
header = binascii.hexlify(binascii.unhexlify(version)[::-1]).decode('utf-8') + \
prevhash + \
merkle_root + \
binascii.hexlify(binascii.unhexlify(ntime)[::-1]).decode('utf-8') + \
binascii.hexlify(binascii.unhexlify(nbits)[::-1]).decode('utf-8') + \
binascii.hexlify(binascii.unhexlify(nonce)[::-1]).decode('utf-8')

blockheader:000000200eba48f47bc0ab4bb35b230849868bf1d79aeb19006eed460000000000000000fb68998fe1dd4cc22fa1225c2592c27df5331d40d9b33ffce99b26c0aead8ef404d5bc590b3101181e3eef8c
Can someone please post an example of a recent BLOCK HEADER ... i think i m doing something wrong !
I am comparing this hash
hash = hashlib.sha256(hashlib.sha256(binascii.unhexlify(header)).digest()).digest()[::-1]

with the target "000000000001310b000000000000000000000000000000000000000000000000"

Let's take a look at this block, because it only has one transaction (the coinbase): 000000000000000000eb2d0ed97a7b2cff7f1408417dca83908004beb6fd9b95
Let's grab the raw hex data:

0000002053f7ebc735f54ac8d4ebcc1eeb3d3bdea89603bdd27431000000000000000000ff964ec70ea5a5356a04fdb044ca6c59ffda2dd6be02c63d9ea58fb6d46e01991a22bb590b310118f6df26f801010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff3103b46707244d696e656420627920416e74506f6f6c6b2f4542312f4144362f4e59412f332059bb221ab8080000615c0300ffffffff02807c814a000000001976a914660371326d3a2e064c278b20107a65dad847e8a988ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000

There are 6 things which make up the block header:

First we have the version (4 bytes), 00000020, which is reversed bytes of 0x20000000.
Then we have the previous block hash (32 bytes), also in reversed byte order, 53f7ebc735f54ac8d4ebcc1eeb3d3bdea89603bdd27431000000000000000000 which is this block.
Next we have the merkle root of the transactions (32 bytes), in reverse byte order, ff964ec70ea5a5356a04fdb044ca6c59ffda2dd6be02c63d9ea58fb6d46e0199. Because there is only one transaction, the coinbase transaction, the merkle root is just equal to that transactions txid.
Then we have the time stamp (4 bytes), in reverse byte order, 1a22bb59 which is 0x59bb221a in hex or 1505436186 in decimal.
Then we have the reversed bytes of the 'bits' field (4 bytes), 0b310118 which is 0x1801310b
And then the nonce (4 bytes), f6df26f8 which is 0xf826dff6

Then after the header, we have the byte 01 which means there is one transaction, which follows. That one transaction is just the encoded coinbase transaction, as you can see here.
Of course, only the block header needs to be hashed, not the transactions too.

This is Awesome !! Thanks... All is very much clear now.. except the merkle root. binascii.hexlify(hashlib.sha256(hashlib.sha256(binascii.unhexlify('0100000000010100000000..........4e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000')).digest()).digest()) This gives me "cb7ac0ad06517d90cd5a936aebb8b32205fefec268ac6970c04b528313f3ce26" and not "99016ed4b68fa59e3dc602bed62ddaff596cca44b0fd046a35a5a50ec74e96ff"

That's a witness transaction, so you have to modify it a bit before hashing it to find the txid (you currently found the wtxid). But that's a separate question , remember to accept my answer to your question if it satisfies you btw :)

Yes your answer is perfect, what i was looking for.

So everything in the submitted header of the block is byte-reversed of actual value?  In other words if you want to know the version from the block header, byte-reverse it, and you get the value.  This design is so unnecessarily confusing.

MeshCollider's answer is awesome. I want to add a note. Why do the previous block header hash and merkle root hash need to reverse bytes? And why other fields doesn't need it?
Actually, if you want any transaction's hash, you need to double-sha256 hash. So, the point is: if some data need sha256 digest, and digest stores in the computer is little-endian, some case need to transform to big int in big-endian, so reverse the bytes. And you get the double-sha256 hash in bitcoin. In some case, the big-endian is necessary. e.g. big-int(block-header-hash) < Mining Target?
If you need transaction hash, the result is big-endian too.
For example, a raw transaction hex is:
0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

then, you need transaction hash:
>>> import hashlib
>>> d = '0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704000000004847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901ffffffff0200ca9a3b00000000434104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac00286bee0000000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000'
>>> hashlib.sha256(bytes.fromhex(d)).hexdigest()
'240cf324ec3cf59609733e2a45e1408673306be8dcd4caf3067aa9355a0269e3'
>>> hashlib.sha256(bytes.fromhex('240cf324ec3cf59609733e2a45e1408673306be8dcd4caf3067aa9355a0269e3')).hexdigest()
'169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4'

169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4 is little-endian hash, in the bitcoin, all the double-sha256 hash is big-endian.
In fact, this transaction's identifier is big-endian hash: f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16.
When you need to find some info about this transaction, you need input the big-endian hash:
https://www.blockchain.com/btc/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
and little-endian hash you can find nothing.
Did you get it?

previous block header hash need to reverse bytes, because bitcoin need big-endian.
current block header hash need to reverse bytes, because bitcoin need big-endian.
transaction hash need to reverse bytes, because bitcoin need big-endian.
merkle root hash need to reverse bytes, because bitcoin need big-endian.

OMG! why? I found bitcoin core developer didn't know the reason.

Due to historical accident, the tx and block hashes that bitcoin core uses are byte-reversed. I'm not entirely sure why. May be something like using openssl bignum to store hashes or something like that, then printing them as a number.
ref: http://learnmeabitcoin.com/glossary/txid

There would be no need to check big/little endianes and do byte reversing if all data was stored as bytes instead of some as uint32.  For example getblocktemplate provides the bits field as a hexadecimal string, they could have done the same for version, curtime/ntime.  This design lacks simplicity and is unnecessarily twisted. It's stupid.  Can't believe bitcoin is worth anything.


text:
What's the history behind the first btc exchange
I've found out that the first BTC exchange was "BitcoinMarket.com" but I didn't find any information on it or any other exchanges that started at that time.
So the question is how did this first market came to be? How did it start? Why was it closed? Who started it and why?
I would be really grateful for any more info on this.


text:
Calculate Segwit address from public address
I would like to calculate the segwit address of a public address.
First step:
take the compressed public address:
1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9

do a sha256 on that address:
151de228f6bec7635097f7813786830505d04bf56806f11eb056441fdc917d41

do a ripemd160:
9bbfb2424372d687cf35fd7d1e978f85a11157ca

encode with Base58:
usT1ggHqtEAcGd4ZysWqtxaaQmT

There is something wrong since every segwit address should start with "3". Can someone help me which step it is?
My source of how a segwit address is calculated is: How to get legacy address and private key from Segwit P2SH address? Quote:

You have the private key so you can just derive the address from there. Get the corresponding public key, hash it with SHA256 and then that result with RIPEMD160. Then perform Base58Check Encoding on it.

next to my answer below, see at the response here: https://bitcoin.stackexchange.com/questions/46455/verifying-a-bitcoin-trx-on-the-unix-cmd-line-with-openssl

Firstly, it is very dangerous to convert a public address to a different form and then use it, because the owner of that address will not be expecting payments on other forms, and could result in fund loss. Only use addresses which the recipient has asked you to use.
But there is a difference between a compressed public key and an address. Bitcoin addresses starting with 1 are base58 encoded keyhash with a checksum. To get the key hash which is the ripemd/sha256 hash of the public key, you must decode the base58 and ensure the checksum is correct. Then you simply use the keyhash in the redeem script, you don't need to perform any more hashing on it to form the P2WPKH script. Notice that there is no way to know if an address starting with a 1 used a compressed or uncompressed public key before it's spent, so if you tried to convert one which had an uncompressed key, it would be unspendable, very dangerous as I said earlier.
See here for more details: https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address

Java code doing that was pasted here, but mostly without any explanation, so I'll try to explain.
When I was looking information about it, the best example was found in BIP-49 text. We start from the following line:
// Address derivation
keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3

So we have 20 bytes of public key hash: < keyhash >. If we want to obtain legacy key, we simply prepend < prefixByte > (prefixByte = 0 for BTC main) and get < prefixByte | keyhash > array. Then we should do HASH160(< prefixByte | keyhash >), and take first 4 bytes as checksum. So the resulting address looks like < 0 | keyhash | checksum > - 25 bytes total. It is an address in his hex form. To get a common form we should only base58-encode it.
If we want to obtain a segwit-address, first we want to get < keyhash >. We should decode base58-encoded address to an < addressArray > and check the checksum (that last 4 bytes are equal to HASH160 of first 21). If everything is correct, we should drop first one and last four bytes of < addressArray > to obtain a < keyhash >.
The next step is to get a < scriptSig >, simply prepending 0x0014 bytes to a < keyhash > array:
scriptSig = < 0 < keyhash > > = 0x001438971f73930f6c141d977ac4fd4a727c854935b3

We get segwitBytes hashing < scriptSig >:
segwitBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742

And finally, we get an address, prepending p2shHeader (=5 for BTC MainNet, 196 for BTC Testnet) to segwitBytes, and appends their checksum:
// segwitBytes base58check encoded for testnet
address = base58check(p2shHeader | segitBytes) = 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2 (testnet)

HASH160 is following: first we use SHA256 function to hash and than RIPEMD160 on result. The example implemented in Java can be found for example here (function org.bitcoinj.core.Utils.sha256hash160).

you may need to use hex values to do the conversion. Bitcoin doesn't work with strings/chars... When I do the calc at the terminal, I get your result (e.g. for the SHA256 to ripemd160):
printf 151de228f6bec7635097f7813786830505d04bf56806f11eb056441fdc917d41 | openssl dgst -ripemd160
(stdin)= 9bbfb2424372d687cf35fd7d1e978f85a11157ca

But this would be the wrong way. You first would need to convert to hex, like this:
$ printf 151de228f6bec7635097f7813786830505d04bf56806f11eb056441fdc917d41 > tmp_sha256.txt
$ printf $( cat tmp_sha256.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sha256.hex
$ hexdump -C tmp_sha256.hex
00000000  15 1d e2 28 f6 be c7 63  50 97 f7 81 37 86 83 05  |...(...cP...7...|
00000010  05 d0 4b f5 68 06 f1 1e  b0 56 44 1f dc 91 7d 41  |..K.h....VD...}A|
00000020

then you can convert to next step like this:
$ openssl dgst -ripemd160 tmp_sha256.hex
RIPEMD160(tmp_sha256.hex)= db151e871af66b1323893e3f527e22f7684718af

all in all:
$ printf 1L88S26C5oyjL1gkXsBeYwHHjvGvCcidr9 > adr.txt
$ printf $( cat adr.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) >adr.hex
$ openssl dgst -sha256 -binary <adr.hex >tmp_sha256.hex
$ hexdump -C tmp_sha256.hex
$ openssl dgst -ripemd160  <tmp_sha256.hex

returns a string now (56379c7bcd6b41188854e74169f844e8676cf8b8), that is then base58encoded into this address:

39YteymR86cG7V3Kijg8Gm2ST1r4nTeM1b

how did you get 56379c7bcd6b41188854e74169f844e8676cf8b8?

when you don't provide an output file to openssl, and remove the "-binary", then it writes to the console: "openssl dgst -ripemd160  <tmp_sha256.hex". Are you on Windows or Unixoide systems?

No, i'm not on windows.
performing the third step returns
-bash: svn.hex: No such file or directory

oops, I should stay consistent with my filenames. it must be "openssl dgst -sha256 -binary <adr.hex >tmp_sha256.hex". (I did several tries, and first I used filenames "svn", and then "adr" ...). I just double checked it, it works now.

Yeah, i got it now, but converting it to base58 returns 2CffxtJsCdzJEaHXHjSkvb12p12P
tool: http://lenschulwitz.com/base58
Are you using bash or i missed something?

This approach is quite wrong, see my answer

I also get "CffxtJsCdzJEaHXHjSkvb12p12P" as result. Unfortunately, I dont understand whats wrong.

I figured out that there is something missing in front and in the end of "56379c7bcd6b41188854e74169f844e8676cf8b8". Can you help me out? There seems to be a "05" in the front and "6e1b34ba" at the end. Why is that?

Can you help me here? https://bitcoin.stackexchange.com/questions/66957/convert-between-string-hex-byte-wrong-format

nope, sorry, never played with Java and hash functions... but there is a library, where similiar code is used; maybe this helps: https://github.com/ValleZ/Paper-Wallet/blob/master/app/src/main/java/ru/valle/btc/BTCUtils.java

@A.c as I said, this answer is incorrect, you should not hash the address, see my answer


text:
What does a Bitcoin transaction consist of?
I gather that 2400 transactions fit into a 1 MB block.
That's 436 bytes per transaction record.
But what's in a transaction record?
Is there a good Powerpoint presentation that describes how Bitcoin transactions work?
Thanks.

Related: http://bitcoin.stackexchange.com/q/1195/516

Here's an interactive diagram showing the indivdual steps through the diagram:

http://staging.spectrum.ieee.org/static/how-a-bitcoin-transaction-works

A typical transaction (simplified) looks like:
Spend:
   20 BTC from a transaction using address:ABC123

To:
   10 BTC to address XYZ111
   10 BTC to address JKL222

Here XYZ111 is where you want to send your BTC to and JKL222 is your address for the change.
With transations like this you do not know (reliably) where your BTC are coming from. The next transaction will probably spend from JKL222 as ABC123 is all spent.
This in intentional in the Satoshi client so that it jumbles up the change and the sendee's addresses.

can you post a link to a bigger version of the image?

Hm ... they must have expired that URL.  Here: http://spectrum.ieee.org/img/06Bitcoin-1338412974774.jpg


text:
How to lower difficulty on blockchain?
I created a coin (hexco.in)
The problem now is, sometimes some user create pools and use rented mining rigs to mine on my coin. But after a while they stop and my blockchain stucks at a certain block.
My question now is, how can I solve this problem? I only have a homserver and a raspi2 running as mining service 24/7 for my coin and a seednode running 24/7.

Is there a specific use case which your blockchain addresses?

sorry I don't understand your question

Did you create your alt-chain to solve a specific problem?

no not that really. I just want to test the blockchain tech and maybe it will be a good tech for a future project :)

How to lower difficulty on blockchain?

The problem now is, sometimes some user create pools and use rented mining rigs to mine on my coin. But after a while they stop and my blockchain stucks at a certain block.

You could include in your expected difficulty calculation a factor of time, where say, for example, every 10 minutes since expected next block time (supposing you have a ten minute average block time) the expected difficulty is lowered by a factor, say divided by 2.
The problem with this method is that it may allow cheating unless you also carefully control network time. If it is not carefully managed then a cheat could submit a block with a future time and a lower difficulty.

This is not a permanent solution, but you could try organising a fork in which you manually raise the target value. I doubt that this will protect your alt-chain for long though.
You may find a longer term solution with merged mining.

But I could mine with my home pc's for a longer time and it will generate the block after a while? lets say the network h/s drops from 15 mh/s to about 15 kh/s.

It won't really matter how you raise the target value, because it is likely you'll encounter the same problem again in the future. Implementing a merged mining solution could prevent this from occurring again.


text:
Best way to anonymize bitcoin transactions?
https://en.bitcoin.it/wiki/Mixing_service
How do sites like this work? "Mixing services". I know it can be broken and traced back with coinsuduko but how exactly does it wash your coins. I doubt they just wait for somebody else to send in enough funds to reimburse with new coins, how would they go about doing it? Do they send the 1 BTC or whatever amount through 50 or so different wallets in different amounts on a bitcoind and then return the 1 BTC to your set wallet? I've heard of coinjoin, how does it work?
If I was going to send 1 bitcoin from one wallet to another from my website but have the bitcoins "washed" what would I need to do to keep the transactions hidden or at least "Mixed" so it would be harder for the bitcoin receiver to figure out what address exactly sent the coins.
Here is another example of open source coin washing blockchain.info uses:
https://github.com/blockchain/Sharedcoin is all this javascript on user side really necessary (speaking from using their setup sharedcoin.com, not reading over the source which is also javascript.)
Thanks.

The idea behind Coinjoin or Sharedcoin is that funds can be pooled and mixed with several other Bitcoin users to fund new transactions that can't be easily traced back to you.
Here is a trivial example: imagine 3 users, that want the funds from 3 addresses the each control A (0.5 BTC), B (0.5 BTC) and C (1 BTC) to be sent to addresses X, Y and Z respectively. Instead of transferring the funds directly a service could do the following, assuming intermediary addresses:
A(0.5) --> L(0.5) --\
B(0.5) --> M(0.5) -- +
C(1)   --> N(1) --\   \-- Z(1)
                   \
                    \--- X(0.5)
                     \--- Y(0.5)

So the money originally from C gets split and sent to X and Y while the money from A and B gets added and sent to Z. Mixing services do the equivalent but across much more transactions.

What's the reason for the intermediate addresses L, M, and N? Wouldn't it be just as effective (in terms of untracability) if we create one transaction, with A,B,C as inputs (total 2 BTC) and X,Y,Z as outputs? Actually, if the amounts differ, you can still see that Z receives the same amount as input C, but the owner of C can simply overcome this by giving two output addresses Z and W which receive 0.5 each. As long as all output amounts are similar, I'd say this works just fine?

L, M, and N represent the 'service'.

Why does this service need to introduce intermediate addresses of their own? I'd say this only imposes an unnecessary risk: now you have to trust the service with your money.

It's required for the mixing process to happen easily. Otherwise they'd have to give you a big transaction which you would have to sign yourself.


text:
merkle root 2 codes
While trying to calculate the merkle root in python from the data i got from the mining pool.... i found there are 2 different codes.
code 1:
def build_merkle_root(coinbase_hash_bin, merkle_branch):
    merkle_root = coinbase_hash_bin
    for h in merkle_branch:
        merkle_root = hashlib.sha256(hashlib.sha256(merkle_root + binascii.unhexlify(h)).digest()).digest()
    return binascii.hexlify(merkle_root).decode('utf-8')

This is explained in shlushpool stratum document here and also in an altcoin sia mining protocol here . So i think it should be correct.
But there is another piece of code below,
code 2:
def build_merkle_root(hash_list):
if len(hash_list) < 2:
    return hash_list[0]
new_hash_list = []

# Process pairs. For odd length, the last is skipped
for i in range(0, len(hash_list) - 1, 2):
    new_hash_list.append(hash2(hash_list[i], hash_list[i + 1]))

# odd, hash last item twice
if len(hash_list) % 2 == 1:
    new_hash_list.append(hash2(hash_list[-1], hash_list[-1]))

return build_merkle_root(new_hash_list)
#==========================================================================
def hash2(a, b):
     # Reverse inputs before and after hashing due to big-endian / little-endian nonsense
     a1 = binascii.unhexlify(a)[::-1]
     b1 = binascii.unhexlify(b)[::-1]
     h = hashlib.sha256(hashlib.sha256(a1 + b1).digest()).digest()

     return binascii.hexlify(h[::-1])

This one looks more logical from the merkle tree structure point of view which is hashing each pair separately.
For testing them, Taking below as an example of the job obtained from a pool....
[{'id': None,
  'method': 'mining.notify',
  'params': ['59bc8dfc00003829',
   'ceeefd1381f491d9a0ba90b26a495a225e8bfc9f00ecc4250000000000000000',
   '01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff3503226b07000455abc259040bf12d090c',
   '0a636b706f6f6c112f736f6c6f2e636b706f6f6c2e6f72672fffffffff035976a953000000001976a914fc6123f4bfd3a840b4387ab90e9801e98fb17cf888ac8756d800000000001976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac0000000000000000266a24aa21a9edc963e012cb380138e3d16283a094454782879557714d3b0d73fecfe612d01f0600000000',
   ['b32abe89497354ceaa2dff35cc41995d58c19893d517e92e30b4ead75a66970c',
    'ca93a597a29860178f4cd01326f43b080f516f3f81ba6b86b0ff35f5cb206b7f',
    '213f7e41a5b228ec554c1a2e3fe18b1f3e1c23821b1b2b3aa1319d3d616044ca',
    '0941052c2e5864e57a18bfc82d1e7ab15740d4ed7b852cda92bffd3ff622e59d',
    '7ad5af30a3daa89c1244016227cde139d5d54232a673cbf7954f6a1aa26bbc05',
    'e24a96489d5782c6bcde209952a12826cd225b97b9a3ad3142c87dd062136d0b',
    '383a433dc503c8ab4b7beb9dc4a3e07811a1cb9681e2da019cec16966fc727be',
    'f10804628f630bcead6cd1b667d4352cdfb93aea382662456c2caadda3e1b0c9',
    '03e9bf5b6053fe86d272dac8c2a32f08ace6d045799ae499ed7087af21c737c6',
    '3cf338c75d7ef47b0c029d16b5b02340a62ce0a7846910175b021d919dcccc6f',
    '40319623d80cae8a5b1a3e319a962110a08ff40daf40ebf421b9454f20e54dcc',
    'c29e3826153dfc1d10e9e173281d21ad2103bba86bc2930440e7258afca2b957'],
   '20000000',
   '1800ff18',
   '59c2ab55',
   False]}]

Code 1 gives me merkle root as 7cbd55a748aa8e778e0795e33d5bd5a07c9f465cd3de1fef3bf36ea3ac4d56f9 while
 Code 2 gives as 6681ae1409685d71a51ced80ae0c7eacb78d5facb401ece2287543b6cc17e4cf
Since both are not same, so which one is wrong ? I needed merkle root for block header.
In both the above cases, I took extranonce2 all zeros as 0000000000000000 and build coinbase as 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff3503226b07000455abc259040bf12d090cff47c35900000000000000000a636b706f6f6c112f736f6c6f2e636b706f6f6c2e6f72672fffffffff035976a953000000001976a914fc6123f4bfd3a840b4387ab90e9801e98fb17cf888ac8756d800000000001976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac0000000000000000266a24aa21a9edc963e012cb380138e3d16283a094454782879557714d3b0d73fecfe612d01f0600000000 which gives a coinbase hash of 20d0b9a72f1e940e29b064e428f5e037f948c9ede27dfb7e77b1df7d289d1861

The stratum protocol gives you some hashes of specific branches in the merkle tree. They may not be at the same depth in the tree (and I don't think they are). They are only provided so that the miner can change the coinbase transaction by incrementing the extranonce and then incorporating it into the merkle root. The Code 1 merkle root should be the correct one since that is the method that the Stratum protocol docs tells you to do. The other code is for creating the merkle root from a list of transactions, not a list of branch hashes as Stratum provides.

So the merkle_root obtained from Code1 "7cbd55a748aa8e778e0795e33d5bd5a07c9f465cd3de1fef3bf36ea3ac4d56f9" will be used directly in Block Header or it is in display format same as https://blockchain.info/ and i will need to reverse the bytes to put it in Block Header.

It should be usable directly in the block header.


text:
how does dash solve the scaling issues?
I heard dash has some extra features compared to bitcoin like masternodes etc, can someone explain the subtle differences especially regarding the scaling debate

Dash has instasend (one of masternode's services), that should help in case of block overload/increasing # of unconfirmed transactions, and increased block speed/size adds some space to delay clogs like btc experienced last Dec. But i wouldn't say this could replace lightning if you would compare fee rates

The biggest reason why Dash can scale is incentive alignment. Dash splits the block reward between the miners (45%), masternodes (45%) and the treasury (10%).
Masternodes are a special type of node with some extra requirements. In exchange for that, they get paid by the network. Because they get paid, the network can require them to run powerful machines that can handle bigger blocks than what would be possible with volunteer nodes (like what happens with Bitcoin, Bitcoin Cash or Litecoin).
Also, thanks to the masternode layer, Dash is about to release a decentralized API that will allow light wallets to connect to that layer as a class, not an individual (trusted) server. With that, it will be possible to use Dash in a completely trustless way without the need to download the blockchain, reducing the pressure to keep it small because only very specific use cases will require to have your own copy.
There are a few more improvements in the works that will all contribute towards scalability. Arizona State University recently released a paper analyzing Dash scalability:
https://blockchain.asu.edu/block-propagation-applied-to-nakamoto-networks/
As a side note, Dash also has a governance system in place that facilitates decisions around the protocol. That is not technically an advantage towards scalability, but because decisions can be made easily, roadblocks are only temporary. The decisions to go from 1MB blocks to 2MB ones was agreed by the network in less than 48h, saving a lot of time in discussions between parties claiming to represent the best interest of the network but without a real way to prove that.


text:
I am looking for a step-by-step Guide to create a new Cryptocurrency, based on Bitcoin code
I am looking for a step-by-step guide on creating a new CryptoCurrency using BitCoin Code, particularly on Fedora.
Can someone help?
Thanks in advance.

If you have to ask...

It seems some text got truncated


text:
Any way to accelerate transaction for a random cryptocurrency?
I see all kinds of transaction confirmation times on Blockchain.info, from really short to very long (to an unacceptable extent). I wonder if there's a way to control that in any way. Maybe by giving a bigger reward to the miners? Does the sender even have control over this? I know that Ethereum has some control over that, but is it possible for Bitcoin? What about other crypto coins/tokens?

A bigger amount to the miners won't make them mine the block faster. It will only increase your chances to be in the next block AKA have your transaction confirmed faster.
In short the answer is no, the sender has no control when the next block will be mined, nor can they influence that with higher fees on their transaction.
"Miners" try to solve a mathematic problem using their collective computing power / hashrate.
A higher amount of fees doesn't drive the hashpower up, so it seems logic that the speed of "finding" a new hash / creating a new block doesn't increase.

Senders cannot control when the next block will be mined, but they certainly can influence how long it takes for their transaction to go in a block. If you pay a higher fee per byte than everyone else, you are very likely to be included in the next block, for example.

With nor can they influence that with higher fees on their transaction. I actually meant influencing the speed of when the next block is mined, Formulated that pretty bad.. :)


text:
How do I get number of pending transactions for an arbitrary blockchain
How do I get number of pending transactions (queued and waiting for confirmation) for an arbitrary blockchain? Do I need to download that blockchain? There should be a more adequate way.

Due to the decentralized nature of blockchains, the state of transactions is relative.  A pending transaction is one that your node has seen and verified as valid, yet your node has not seen a block that includes it.  This might not be the same state that other nodes see.
For example, one-block chain forks are a common occurrence, where there is a disagreement on the network as to which block is the next valid block.  This will usually resolve itself when a block is found on top of one of these two blocks, but in the meantime, there is disagreement about which transactions have been included in a block.
There is also the possibility that your node has not seen a transaction, whereas other nodes (including mining nodes) have.  You wouldn't have this transaction in your list of pending transactions, even though there are miners actively attempting to include it in a block.  The opposite is also true, where you have seen a transaction, but miners are ignoring it for whatever reason.  Bitcoin is actually pretty good about these scenarios, so it normally isn't an issue, but it is a possibility.
In addition, there is the question of a transaction's validity.  Even though you can be fairly certain that a transaction is valid without independently verifying it with a downloaded copy of the blockchain, you can only be completely sure if you do independently verify it.  If your node is ever wrong or in disagreement with the network about a transaction's validity, then you may consider it pending whereas mining nodes will never include it in a block.  Again, the opposite is also possible.
In order to see which transactions your node (assuming Bitcoin or Bitcoin-based) has "pending", you can use the getrawmempool RPC command.
Further reading:
bitcoind getrawmempool without downloading the full blockchain
Is it possible to view unconfirmed transactions with the bitcoin client?


text:
Do the all coins/tokens have the corresponding network exploring sites/tools?
I see that Bitcoin has Blockchain.info, Ethereum has Etherscan.io. What about other coins and tokens. Is it obligatory for the given coin/token to have such blockchain exploring site/tool, is it a best practice or a voluntary measure?

All open source cryptocurrency project should have a community which voluntarily elects to support its ecosystem. At the beginning, block explorers for said cryptocurrency project are run on a voluntary basis, but as it gains traction, there will eventually be an economic incentive to provide said service.

Not all of them. I think Ethereum is the luckiest in this regard. Apart from the explorers you mentioned, there are free blockchain analytics tools liks c-hound.ai for further analysis and visualization of ETH / ERC20 data. If only things like this existed for all coins...


text:
bitcoin.rpc python library problem
I am working through Master Bitcoin. I got the bitcoin client up and running. I am now trying to access the client from python. In the example, there is a line that says from bitcoin.rpc import Rawproxy.
I get the error message no module named rpc. When I run pip freeze, I have python-bitcoinrpc==1.0 listed. Why can't this module be found?

in debian =)
sudo apt-get install libssl-dev
pip install python-bitcoinlib
 or
pip3 install python-bitcoinlib

Thank you. That worked. Can I ask how you knew this? there seems to be no association to the library name in import and what you install. I looked everywhere online trying to figure out the library.

First, install libssl-dev:
sudo apt-get install libssl-dev

Install python3-pip if not yet:
sudo apt install python3-pip

Lastly, install python-bitcoinlib:
pip3 install python-bitcoinlib

In the example code, it is
info = p.getinfo()

Ran the example, I got "bitcoin.rpc.JSONRPCError: {'code': -32601, 'message': 'Method not found'}"
Change it to:
info = p.getblockchaininfo()

(see https://bitcoincore.org/en/doc/0.21.0/rpc/blockchain/getblockchaininfo/)
It works fine. I got the total number of blocks. In my case, it is 682903.

bicoinlib is the module you try to use to handle bitcoind, bitcoin-cli in python,  rpc module is part of bitcoinlib.
libssl-dev is needed to handle SSL and TLS cryptographic protocols .
if bitcoinlib not work in newer bitcoin core versions 0.15 or newer just use raw bitcoinrpc.authProxy module.


text:
getblockcount is returning incorrect count
I am very new to bitcoin but finally managed to get it all installed and compiled. I am following along with Mastering Bitcoin.
There is an example to use getrawtransaction as follows:
bitcoin-cli getrawtransaction  0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2.
I get the error no such mempool transaction. Using block explorer, this transaction appears in block 277316.
I noticed that when I run bitcoin-cli getblockcount, I only get 180024, which was mined in 2012. Why am I getting such old data?

I get the error no such mempool transaction. Using block explorer, this transaction appears in block 277316.

Unless you're running with the -txindex command line option, or a txindex=1 line in your bitcoin.conf file, getrawtransaction only works for mempool transactions (not transactions already in the blockchain).

I noticed that when I run bitcoin-cli getblockcount, I only get 180024, which was mined in 2012. Why am I getting such old data?

Presumably your bitcoind is still synchronizing with the network. This may take hours (or even days, on slow hardware).

Wow cool a core dev answering my question! Thanks Pieter. You were right about the sync as it is now much higher. What do you mean by "only forks"? Still pretty new to this.

Oops, that was typo. Fixed.


text:
Failed CHECK(MULTI)SIG operation - BIP143 hash pre-image
Using Blockstream's api to broadcast a raw transaction to the Bitcoin testnet, I encountered the following error:
sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)"}

I've noticed that many people have ran into a similar issue before. However, all of the proposed solutions didn't fix my issue. I've looked at the Bitcoin source code on Github and determined that the data I am committing to my hash for signing is incorrect.
Below is the hash pre-image that I'm creating for bip143 p2sh(p2wpkh).
    nVersion:     01000000
    hashPrevouts: 4f3c0f6726ec7f020da2a01598d1741225ea429a34bfdd4c4af2a1c9e45a9bed
    hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
    outpoint:     b9d615615976600739be12a67f326836e4256d7d1c4fe50163536ad8dd7647c301000000
    scriptCode:   1976a91499f27cf1ecb8c1a4c20bdbcdc7992cdb12c9ee5d88ac
    amount:       6981680000000000
    nSequence:    ffffffff
    hashOutputs:  57dbf9cb180c89fe35000b693ea089e521097e6d3f504cfec1620325fcec0036
    nLockTime:    00000000
    nHashType:    01000000

This issue is related only by the error message, not by the solution https://bitcoin.stackexchange.com/questions/61030/got-64-non-mandatory-script-verify-flag-signature-must-be-zero-for-failed-chec?rq=1

After a while of debugging, I was able to find the issue.
My previous assumption that I was committing the wrong data to the hash was correct.
The transaction ID that is needed to construct hashPrevouts and outpoint was incorrect. I needed to reverse the bytes of this value for the hash to be correct.
For example:

b9d615615976600739be12a67f326836e4256d7d1c4fe50163536ad8dd7647c3 (a searchable txid on Bitcoin testnet)

becomes...

c34776ddd86a536301e54f1c7d6d25e43668327fa612be39076076596115d6b9.

In summary, my advice would be to step through the interpreter and reevaluate your assumptions of all the data that you're committing to the hash for signing.
A little bit of code never hurts,
Typescript: Buffer.from(transactionId, "hex").reverse().toString("hex");


text:
What is the format of the value of a transaction in the litecoin ledger
Feeling a little silly here, I can decode the entire rest of the data in the blockchain, but the "value" field of a transaction output makes no sense.
[0,-14,5,42,1,0,0,0]

This decodes to "50.00000000" but I can't see how.
The remainder of the block decodes correctly, so I am fairly sure I'm looking at the right data. It doesnt seem to be in the same format as the bitcoin value (/10^8)

@NickODell I tried that, if I interpret it as a 64 bit big endian I get 15861034, as little endian I get 705032704

The transaction format was never altered in the clone Tenebrix or its clone Litecoin. The bytes you have posted are correct, and do indeed decode to 50 BTC when read out as an unsigned, little endian, 64 bit integer.
~> python
>>> import struct
>>> struct.unpack("<q","\x00\xF2\x05\x2A\x01\x00\x00\x00")[0]
5000000000

Thanks, I was using Java's .getInt() rather than .getLong()


text:
how to transfer genesis block reward for blackcoin?
So my genesis block has a reward setup but I want to send it to my wallet. can you please tell me how? I am using black coin

The reward of genesis block is unspendable.
see https://en.bitcoin.it/wiki/Genesis_block


text:
Where can i see my BitCoin addresses?
How can i see all my BitCoin addresses?
Background
If i send a payment to someone (e.g. 0.35 BTC), the BitCoin protocol is unable to send just 0.35 BTC to someone. For example, if i own 1 BTC, and want to spend 0.35 BTC, then a transaction is created so send my entire 1 BTC to two different people:

0.35 BTC to [destination addresses]
remaining 0.65 BTC to [an new randomly generated address that i own]

This was horribly confusing thing to me, and nearly everyone else. Most people assume that if they backup their public and private key, that they have backed up their wallet.
Unfortunately, you do not have just the one address that appears in BitCoin-qt, you own n secret addresses, that are not visible in your wallet.
A Concrete Example
Lets take a real transaction from the blockchain:

Source Address
18888888PPJ8oGeqR6AKmoiKUme9da48Xf: 2.3899 BTC
Destination Addresses
1FvLq2vz7neRJeLk1uXGjg1Jk8FCiaHnwk: 2 BTC
18888888PPJ8oGeqR6AKmoiKUme9da48Xf: 0.3898 BTC

Out there is a guy who owns address 18888888PPJ8oGeqR6AKmoiKUme9da48Xf (which had a balance of 2.3899 BTC). He then spent 2 BTC on something. The "change" is then routed back to a new address inside his client (18888888PPJ8oGeqR6AKmoiKUme9da48Xf)
You never see this address
The problem is that now you own another address; another randomly generated public/private key pair. If you lost your wallet right now, and restored from a backup, you would not have access to that change, because you don't have the key pair for this new, secret, hidden, address.
You only backup the key pair for your single "real" address. With every transaction BitCoinQt creates internal, secret, invisible addresses. They are hidden inside your wallet.
i want to backup all my public-private key pairs to paper. But before i reach that point, i want to be see all my public-private key pairs. i need to see all my addresses.
How can i see all my BitCoin addresses?
BitCoinQt: v0.8.1-beta
Alternatively, in order to ensure the security of my BitCoins, after every transaction should i generate a transaction

From: me
To: me

so that all my coins end up in a "real" address, which i can then backup? Is that something that is a best practice.
Losing BitCoins because my money was sitting in secret addresses was...depressing.
Bonus Chatter
From the BitCoin wiki entry for Change:

The wallet file contains the private keys for change addresses, and they can receive and send coins normally. However, the GUI in the default client does not display them in the address book.

Also note: i'm not talking about backing up to a wallet.dat file. That will backup my wallet, but to a file. i have a backup of my single address; which is insufficient because my single address no longer has any bitcoins.

@MeniRosenfeld My simple Bing search led me to http://bitcoin.stackexchange.com/questions/3706/where-can-i-see-my-bitcoin-address

I would say since we're talking specifically about change addresses not showing in the GUI that 9077 would be more applicable.

You can use pywallet to look at all the addresses and keys.
The console command listaddressgroupings should also give you all your addresses, grouped by known co-ownership. You can then use dumpprivkey to get the corresponding key.
However, backing up just specific keys is not a recommend practice, you should back up the wallet file. If you do want a more concise method, you should use a client that supports deterministic wallets.

Are there any clients that support deterministic wallets?

@IanBoyd: Armory and Electrum. Bitcoin-qt 0.9 will also support this AFAIK.


text:
CoinBase App limits Requests
Coin base recently prohibited me from making a bitcoin request with a pop up saying I already made too many requests.  I had maybe 3 requests that day.  Any one else see this?  What is the purpose of limiting requests?

Take a look: https://developers.coinbase.com/api/v2#rate-limiting
The limit is quite high, it is really strange you received an error response. I suggest you to contact their support, and meanwhile changing your API key (if you're using one) could be a good idea.


text:
How long is it reasonable to wait for an unconfirmed transaction?
Approximately 18 hours ago I made 2 transactions of similar value (approx 0.02 BTC each). This was sending bitcoins to 2 seperate address's. The transaction fees were approx 1% of the values sent. Any transactions I have conducted in the past have been more or less instant, so I am a little concerned that 18 hours have elapsed with 0 out of 3 confirmations on both.
What do I do now? Wait longer, if so for how long?
I have seen suggestions of sending the payment again and increasing the transaction fee, but how can I be sure that after I send the new payment then the original wont clear after it also, meaning double funds have been sent. If I do redo the transaction how much do I increase the fee by?
Any advice would be much appreciated.

Is not usually intended to add the duplicated link too?

It has now confirmed after 4 days.


text:
Bitcoin unconfirmed transaction help me please
Been over 24 hours unconfirmed Transaction please help !!!
13fsWbUWdAPY9BajN7oiMerJSvw66eSYi2  It never takes this long
Thank you

The bitcoin network is overloaded. You must wait 1-3 days before your transaction will go through. There is nothing you can do now but wait.
Next time, you may send transactions with a higher fee so a miner gives it more priority.
Don't spend any money on a site that claims they can speed up your transaction. They are scams.


text:
Unconfirmed balance Multibit
I have read a lot of threads regarding this but haven't sovled it. My scenario is this.
I have saved all the .zip.aes Multibit files on my Dropbox. Now I have reinstalled Windows on my computer and trying to set up Multibit again. I have the wallet words and password.
I have set up my wallet to use the same folder on my Dropbox where my .zip.aes files are. The secret word and password worked great. The balance of my account is correct, allthough I get the "Unconfirmed" in front of the balance.
I have also downloaded Bitcoin core which somebody stated would work. Also tried "Manage wallet > Repair wallet" with no success.
How do I solve my problem?

What version of MultiBit is this?

You must import your wallet into another wallet program like Electrum. There is no solution and Multibit support will not answer your ticket or email, as they ignored me as well.

Here's instructions for how to do so. https://bitcoinelectrum.com/restoring-your-multibithd-wallet-in-electrum/


text:
New wallet per customer, or new address?
So I'm in the process of starting a new service, but want to make sure I build the foundation correctly from the start. When customers deposit to their user account on my service, I need to understand whether I should be using one giant wallet with a new address for every customer and assign that address in the database against their user, or if I should generate a new wallet (with, presumably, new seeds) on signup for every customer, so each customer has their own unique wallet. What is the best course of action here? One thing to be aware of is how the backup process will go, and any potential race conditions (say someone generates themselves an address and sends coins, but the server gets wiped out and the backup doesn't have that last 10 seconds of activity, so the address that was generated can't be tied back to the appropriate user).

Do you take custody of the funds when they are deposited or are you trying to resell a wallet product?

If you are looking to accept deposits from your customers then you should create one deterministic wallet using software like electrum and the install the extended public key aka xpub aka master public key (MPK) on the server. Then from that you can generate all the addresses you need.
The above creates a watch-only setup where you can generate addresses to receive bitcoin but not spend. So in case someone compromises your server they learn your entire transaction history but they can't steal from you. In order to spend the money you need to use the seeded wallet on your PC.
In order to associate addresses with users you would make a note of it in your app's database.
If you want to associate addresses with users in some deterministic fashion then you can assign each user an ID number and a counter which will serve as an address index. Then you can devise an appropriate derivation path that incorporates those two things. So for example Alice could be user ID 5430. Alice's deposit addresses are m/5430/i where i is the counter in the database. First Alice address would be m/5430/0, second would be m/5430/1 and so on. The user ID would not change once a user registers so even with slightly older backups as long as you have the user ID you can increment the counter until you get to the correct one.

The best thing to do is make sure that each customer has their own wallet, with a recoverable phrase.
You mentioned you are using a server, which is unwise as hackers will be looking at that as a big bull's eye.
It sounds like you are making an exchange.
So what they do, is they have receive addresses which are real and on the blockchain. Each user is assigned an address where they can receieve X amount of BTC.
The send addresses however, are in the database, and the database keeps track of how many BTC you have internally.
When you ask to send BTC to someone, the database checks whether that someone is also in their database based on the toAdress, if so, then just minus amount from you and add amount to other person. This happens off the chain.
If not, then they minus the amount from you and send the BTC from one of their own addresses.
You should get someone to build your system for you, as you are dealing with people's finances, and one wrong move could leave you like Mt. Gox
Good luck!

Down voted because a) addresses don't have to be broadcast or "on the blockchain" before you can use them b) you can't limit how much money someone sends to your address c) there are no from addresses in bitcoin

I did not use the proper terminology like UTXo because OP does not sounds like he knows that much about the blockchain. Also the OP sounds like he wants to build an exchange. Exchanges normally work by doing all exchanges that happen inside of the exchange via their own database.
If you can tell me where I went wrong barring the terminology, then I will be happy to change. Blockchain is a difficult concept and I may have mistakenly said something out of place, let me know

I've explained where you went wrong above.


text:
How do LocalBitcoin's merchants prevent volatility risk?
For example, how does a Bitcoin merchant (someone who buys and sells Bitcoin as a business type deal to make commission) prevent the losses induced by the volatility in the market? I.e., say you buy a Bitcoin on an exchange worth $10,000, and then list it on LocalBitcoins, and the price of Bitcoin drops to $9,500 in the mean time. Now your say 2% commission doesn't cover the cost of the price drop. Do traders just eat these losses and par them off as luck, or is there a way to peg their movements so that they are unaffected by this volatility?


text:
Spreading reward of a block over the miners proceeding it
Say I want to implement a rewarding scheme that spreads the reward of a block over its own miner and the miners that build on top of it. Is it possible?
More concretely, say each of my blocks bring 10 BTC(Coinbase+Tx fee). Let's say a miner mines a block. I'd like him to receive only 5 BTC. Whenever someone else mines on top of his block, I'd like him to receive the remaining 5 BTC.
Can one create a cryptocurrency like this by adjusting the generation tx and ensure no one can steal others reward?

What do you believe would be achieved by doing this? What is your objective?

Discouraging block dropping. See: https://dl.acm.org/citation.cfm?id=2978408

I don't believe this would disincentivize Undercutting attacks as they are described in the paper. If this became a protocol rule, all subsequent blocks, no matter what fork or chain they were built on, would have the 5 BTC reward from the previous block, but would also lose 5 BTC to the next block built on it. The effect cancels itself out leaving an effective 10 BTC reward for finding a block. A solution to Undercutting attacks would be to encourage miners not to fill their blocks with transactions with the highest fees, but to leave some high fee transactions for the next block.

@MatthewStannard This is merely a sketch of an idea. I was just curious whether this is theoretically possible or not.

Can one create a cryptocurrency like this by adjusting the generation tx and ensure no one can steal others reward?

You can implement whatever consensus rules you like if you create your own altcoin :)
Unfortunately the thing which makes this difficult / impossible in bitcoin is the fact that coinbase transactions only mature after 100 blocks are mined on top. So while it would be nice in theory to include an extra 5 BTC output from your coinbase transaction that the miner of the next block could spend, it would not be valid, because the coinbase would not be mature. From what I can think, it would only be possible to do this safely to let the miner 100 blocks later claim the coins. That would still provide an incentive, especially if most/all blocks did this, then each new block would usually get 5 BTC from the block 100 blocks behind it.


text:
Time/memory complexity of Bitcoin API calls
Is there a way to see the time/memory complexity of Bitcoin's API? For example, bitcoin-cli getblock "some-header-hash" fetches the block with a matching hash.
How is this implemented under the hood? Does it do a linear scan of the entire blockchain all the time or does it keep a (key, value) table where keys are header hashes? I'm concerned with the implementation as given in http://chainquery.com/bitcoin-api.

Bitcoin Core maintains a LevelDB database (a key-value database) that contains the chain status data. This data includes the block headers, the block locations on disk, the UTXO set, and a few other things.
For blocks, the chainstate database has the block hashes as the key and block headers with some extra data appended as the values. The extra data also includes the block's location in the blk*.dat files (file number and byte offset within the file for the beginning of the block). So looking calling getblock just means that the key-value pair for the block hash is taken from the LevelDB database which I believe is O(nlog(n)) (IIRC it uses some kind of tree as the backing structure). To get the block itself, the lookup is O(1) as it just has to read a specific file at a specific offset.
Very few RPC calls in Bitcoin Core actually do any sort of searching through the blockchain. Most things are either stored in a database or a reference to its location is stored in the database so the item itself can quickly be retrieved by or following a database read.


text:
Why maturity rule on coinbase tx requires too many confirmations w.r.t an arbitrary tx?
For an arbitrary tx, it is often said that 6 confirmations is sufficient. However, maturity rule states that coinbase tx can't be spent until it receives 101 confirmations. Why do we have this disperancy?
Why 6 confirmations on coinbase transaction is not considered as sufficient for example ?

If a normal tx is honest, has 6 confirmations, and there happens to be a reorg 6 blocks deep, the tx will just go back to the floating pool, and join one of the next blocks, with no harm done to any party.
If a coinbase tx has only 6 confirmations and there is a reorg, the original coins vanish from existence, invalidating the transaction, and any subsequent transactions that depend on it. These transactions can no longer be accepted into a block, and even if all parties involved are honest and willing to go through the effort of resending, this cannot be done because the original miner no longer has coins to send, and neither do the other parties.
Since a reorg invalidating a coinbase tx is catastrophic, a safety net of 100 blocks is required to make the chance of this happening vanishingly small.