text:
Did Satoshi object to embedding data in the block chain? Why?
From this post:

Our beloved Satoshi is on record that he doesn’t think it appropriate
  to embed data willy-nilly in the block-chain

Is this claim true? If so, why did he object?
I don't think it's "wrong" in any sense to embed data in the blockchain, because you're essentially paying for it. Since the protocol allows it, it is a legitimate service.

Sorry, I was a bit lazy with that claim. I remember reading a quote by him in the forums to that effect, but I haven't found it again to post a link to it.

"I don't think it's "wrong" in any sense to embed data in the blockchain, because you're essentially paying for it." You're paying the miner, but then everyone else suffers latency having to download the huge thing.

He supported IsStandard, but he was not against small amounts of arbitrary data. Satoshi said:

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.

He always promoted putting hashes in the chain instead of the arbitrary data itself, though I don't know whether he was strongly opposed to the latter.

I can't answer your questions about whether it's true and why.
It's possible that he would've taken that stance because sensitive information could be put into the block chain. Consider the consequences if some of the following examples were included in the block chain (and thus stored on every PC running the client):

Diplomatic cables from Wikileaks
Illegal pornography
The name of someone who has name suppression granted by a court
The private key for an important encryption algorithm (eg this one)

While some activities making use of Bitcoin may be illegal in themselves in some countries, storing data such as the above in the blockchain would create additional legal problems in many countries.

Bitcoin itself could be made illegal in some countries, regardless of the content of the block-chain. This does not mean people living in other countries should not use it. Same goes for messages. In any case - it is a possibly unavoidable feature of the current protocol. Your post seems to be more a comment than an answer - I'm not debating whether it's ok, I'm asking about Satoshi's opinions. I've asked the original author to answer here as well.

It's far too long to fit in a comment, and gives a very plausible reason why Satoshi (or anyone else) would object to the idea, so I very much believe it is worthy of remaining an "answer". Sometimes, an answer to a slightly different question is more worthwhile than a strictly accurate answer to the stated question.

As you wish. I won't accept it though :)


text:
Is two-phase encryption planned for the standard client?
Currently, the standard client supports encryption, but only for actions that change its state (send money, generate address).
I would like the client to require two passwords - one to view any information, and another for mutating it (send money, generate address).
Is this feature planned?

No, it is not planned.
I'd suggest writing some JSON-RPC proxy code that takes RPC commands, checks to see if they're safe (or checks to see what password was given), and if they are authorized forwards them to bitcoind and passes through the result.  There is a lot of good Python code for json rpc clients and servers, although JSON-RPC is a simple enough protocol it shouldn't be hard to create a proxy in any language.

I'm not thinking of miners for this feature, but rather end users.

source: Stack Exchange

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

sort: votes


text:
What are the transaction fees with Ripple.com?
https://ripple.com/how-ripple-works/

While Ripple does not charge a typical fee for profit, each
  transaction does require a small portion of a ripple (equivalent to
  ~1/1000th of a cent) for security.

This seems to assume a certain conversion rate between Ripples (XRP) and real world money. How much in XRP is the TX fee?

The default fee for a transaction is 0.00001 XRP.
But the fee is not fixed. Quoting the wiki:

Transaction fees are adjusted based on two factors: base fee and load
  fee
base fee: long term fee adjustments
  Since transaction fees are
  paid in XRP and the price of XRP may change overtime, to keep the
  price of transactions affordable, Ripple uses an adjustable "base fee"
  to specify the cost of transactions.
load fee: short term fee adjustments
  The "load fee" can rise quickly to protect the network
  from attacks and keep the network functional under heavy load.

The fee schedule is changed using consensus, quoting. D.Schwartz:

A node can introduce a transaction to change the base fee. If a
  trust-weighted majority of nodes vote "yes" on the transaction, it
  will be incorporated into the ledger and the fee will be changed.

Long term adjustments: When we want to change the base fee or multiplier, we just release a new version of the software with a new base fee (or publish a new fee schedule). People can tweak that, but they probably won't. People might not upgrade, but they probably will

@ripper234 they are talking about software "server-side", I hope.

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


text:
How to create a sending address with Bitcoin Core?
I downloaded Bitcoin Core and I'm just having a look around and I can't for the life of me figure out how to create a sending address.
I'm using a site to buy stuff and to register I need to "Setup your payout addresses" which is "the address where centralised escrow is released to the seller, and where buyer refunds are sent".
So, what do I do?

Welcome to Bitcoin.SE! Since you are new, you might find our [tour] interesting; it gives an overview how our site operates. You might also find the questions collected at
I am new to Bitcoin, how can I get started? useful. :)

You are not looking for a sending address but for a receiving address!
Coins always come from the address that you received them to, so one doesn't need special "sending addresses". Your purpose here is to enable the escrow to send you a refund in case something goes wrong with the purchase.
To find out your address, switch to the "Receive" tab:

The "Receive" tab will show you a list of all your addresses. The list will be empty at first, so you have to click "Request payment", which will open a new window showing your address:

You'll want to copy the alphanumeric string after "Address:" in the last line. To show the address again after closing the window, you can double-click the line in the list, or select it and click the "Show" button in the bottom left corner.

Murch is correct.  There is no such thing as a sending address, only receiving addresses.  The core application you installed created for you a private key, automatically.  This private key is like a fingerprint. There is a mathematical 'certainty' that you are the only person in the entire world who holds that private key.  With that private key, your bitcoin core application is able to sign and encrypt special messages which tell the network that you 'own' coins sent to specific addressees.
Addresses, to which bitcoins are sent, are generated from the private key using Elyptic Curve Cryptography.  These functions are one way, and mathematically impossible to reverse.  This means you can generate many addresses from one key, but you cannot generate the key from any of the addresses.  The math works only in one direction.
You prove to the network that you own an address by providing a public certificate generated from your key, and this certificate can be used by the other machines to 'prove' that you are the owner of the key that was used to generate the Address, and this lets you spend the coins there.
As I read back over my explanation, it all sounds very confusing, but the one thing to remember is that your private key is held by you and NO ONE ELSE (Very important!).  The Private Key generates a Public Certificate and your Wallet Addresses, and the Private Key also encrypts the "Please send my unspent transactions to this new address" message in a way that people can safely verify that you have permission to send that message, which spends your coins.
Modern Bitcoin wallets will generate a new Address string every time the Address is used in a Bitcoin transaction to prevent people from using cryptographic tricks to 'fake your signature'.  This means that each time you need to have someone send you bitcoin, you should send them the address from your wallet, and you should never save addresses of other people for repeated use.  This is better for the security of the system and the safety of your transactions.
Welcome to Bitcoin!  I hope you find it as wonderful as we do.  If all of these seems very confusing, you may feel releaved in knowing that your wallet application handles all these complexities for you.  For most Bitcoin users, it is a simple 'point and click' life, and they never need to worry about addresses, certificates, keys or signed messages, because the software handles it invisibly in the background.
The Bitcoin Core is the first wallet application, and probably one of the most popular.  Other wallet applications also exist out there, and I encourage you to experiment with them and find one that you absolutely love, because they each have different interfaces, and some are easier to use than others, but for each person, there is usually only one or two that they absolutely love!


text:
Is "1Wh4bh" a valid Bitcoin address?
The bitcoin address 1Wh4bh looks so short. Is it even a valid address?
If yes, can we send bitcoins to it?

Interestingly, blockchain.info returns "Input too short" for "111" and "aaaa", but "Checksum does not validate" for "1111". So it seems blockchain.info does assume that 4 characters is the shortest possible address? (I haven't found valid address with only 4 characters though)

More info from a quick Google search:  it appears in test data, and may be from a litecoin wallet, not bitcoin.  Of note in the first link is that the next test value, 112edB6q, also shows up on blockchain.info.

As to elaborate on why this is accepted at all at blockchain.info, 1Wh4bh is:
>>> import base58
>>> bytes.hex(base58.b58decode('1Wh4bh'))
'001406e058'

Following https://en.bitcoin.it/wiki/Protocol_documentation#Addresses, it only contains the preface of a bitcoin address ('0x00'), and the checksum: '1406e958'. In fact, the double SHA256 of 0x00 (as the hash160 of the public key is not indicated) is:
1406e05881e299367766d313e26c05564ec91bf721d31726bd6e46e60689539a

The first 4 bytes coincide, so the checksum is right.
Because of this, the bitcoin address could be well formed... in a sense.... I suppose this is the reason why blockchain doesn't reject it.
But in fact, as no public key is indicated at all because no public key would produce a hash160 equal to the null string, it cannot be used for any purpose.
Note, also, that a null (or less than 160 bits) hashed public key is incorrect even in the case of (all) leading zeros, because Base58Check algorithm used by bitcoin preserves all leading zeroes.

No, it is not valid as explained here:

A Bitcoin address, or simply address, is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a bitcoin payment. Addresses can be generated at no cost by any user of Bitcoin. For example, using Bitcoin Core, one can click "New Address" and be assigned an address. It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

https://en.bitcoin.it/wiki/Address

No, it is not valid, and I have no idea why blockchain.info shows it as such.

normally I would say this should be a comment - but I see yours carry more weight http://github.com/bitcoin/bitcoin/graphs/contributors

I think you're right. Without some background or reference information this is not really a good answer.

There are different levels of correctness here.
A bitcoin address uses a simple checksum, whose purpose is just to detect accidental mistyping of an address in the hopes of preventing transactions going wrong due to simple typos.  Credit card numbers also use a simple checksum for the same purpose, though in the case of bitcoin it's a 32-bit portion of a SHA256 so much less likely to match by chance, but not cryptographically so - it is after all only for detecting mistyping.
The checksum is easy and fast to calculate so a form on a page can do a quick check to validate the number without having to do any heavy processing or contact any third parties.
In this case, the address passes the checksum test but results in an address that is too short.  A form on a page should not accept this as a valid bitcoin address even though the checksum is valid, because it should fail a length test.  In fact, as stated in another answer this is a "null" (one zero byte) bitcoin address with a checksum.
Even if a bitcoin address passes the checksum and length test would still not indicate that using it would be successful.  For example, padding this address out and re-checksumming it would still not be usable.

It is not a valid address, because blockchain.info doesn't even show it Hash160. Wallets send money to Hash160s, not addresses, which means money can't be sent to it. If it can't have bitcoins, it's not a valid address then.


text:
Does the unique ID of an Armory wallet give any information about it?
I want to create an encrypted paper backup, and to do so I'm thinking about encrypting only the root key and the chain code, so that when I have to recover it, I don't have to type a lot.
But I'm wondering if leaving the unique ID unencrypted can give any sort of information about the wallet to the person who finds it, like what kind of pattern to look for, or how much bitcoin there is in the wallet.
For example, it's been said that for extra security, you shouldn't have your savings in a address if its public key is known, because in the future the private key could be found by using quantum computing or whatever. I know the unique ID is a different thing, but still I want to know what it is, how it is generated, etc.
Another way to ask the question: What do I need the unique ID for in the paper backup, if all I need to recover it is the root key and the chain code? Can't I just remove the unique ID from the paper backup? Would that be theoretically more secure?

According to the source code the wallet ID is an address byte and the last 5 bytes of the first address, encoded as base 58. The last 4 bytes of the address are part of a SHA-256 hash of the first part of the address. The address itself is the private key hashed once with SHA-256 and once with RIPEMD-160. So the only information contained in the Wallet ID is checksum information, which is also contained in your publicly available address. The address is available since it is the one you transferred your coins to.
I'm pretty certain that having the wallet ID visible isn't going to leak any information.


text:
Need help recovering lost bitcoins from a crashed computer's wallet file
Hi so a few years back I purchased 25 bitcoins, after I purchased them I placed them in a wallet, my computer crashed and I got a new one forgetting about the bitcoins, now seeing the high price for the coins I want to know if there is any way to recover them or if they are lost forever.

What was the name of the wallet you placed them in?

I forgot the wallet I had stored them in, it deleted the wallet and everything, if I could just find the wallet I know my email I used and the password, i am having trouble finding what wallet I used

Is there anyway I could find the wallet I used?

Is there anyway I could find the wallet I used?

Well, if you do not know the name and dont have your history from that device, your screwed.

I want to know if there is any way to recover them or if they are lost forever.

Well, from what I have seen of this post, you do not have any information of the wallet whatsoever, you may have lost them forever if you dont have a backup.
However, if you have any of your old computers files, we may be able to recover it. If not, sorry mate.

It sounds like the wallet was set up using software installed on your local computer, perhaps the Bitcoin-QT (aka Bitcoin Core) client, Electrum, or maybe Multibit. You'll need to obtain the private keys for the addresses that received the bitcoins (unless they were stored with an online wallet service, in which case you'd be wanting a website login and password, if the service still existed).
In the case of Bitcoin-QT, there is a file generated called wallet.dat that contains the private keys. It may have been encrypted with a password to protect against hacking.
If you can recover the file, and get through the encryption that may be enabled, you would probably be able to recover the bitcoins by reinstalling the Bitcoin Core client (see bitcoin.org) to open the wallet (assuming it was a Bitcoin-QT wallet, otherwise you'd use a different client).


text:
How can I claim my BCH if my BTC is held with Block.io, a multisig address?
Title is enough, but to elaborate, I've been trying to do this for a long time with no avail, I am trying to cash out my BCH, but first I need to acquire it.

There is a solution. I've got my BCH today from block.io which was already empty but it had a BTC on the day of fork.
So what you have to do is:
First of all you should get from security settings of you block.io profile: "Redeem Script Hex", and two private keys. (actually you will have some more strings and values but only these three required to claim your BCH.
After that:
Go to http://www.motelmaya.com/BCH/BCH.html
I know this seems strange and may cause doubts and believe me I wasn't sure too. But the real deal was: getting BCH (I had 0,5 of BTC at block.io wallet) or getting nothing.
So, then:

Click +TX or New -> Transaction.
Enter the redeem HEX that you received from block.io in the first box (Address, WIF key or Redeem Script)
Click on "Advanced options" -> "Network" -> Settings and change the network to "Bitcoin Cash (mainnet)"
Click New -> Transaction once more.
Put in the amount you want to transfer and the address you are sending to (your new BCH wallet I guess - I've used my blockchain.info wallet address), make sure that the fee is not too high (I've entered something like 0.000317
Click "Submit", you will get a long HEX string. copy it
Click "Sign", paste the copied string, paste the first private key from the  block.io to the "Private key" field, click "Submit", copy the string.
Paste the string into the second box (below the "Private key" field), paste the second private key from the block.io, click Submit, copy the output
Go to "Broadcast", paste the string and click "Submit".

That's it. You will recieve TXid which you will be able to check at https://bitcoincash.blockexplorer.com
Actually all regards should go to ohad serfaty but I can't comment the post where he advised this method because of low reputation.
Good luck!

You already have the answer in your title.
BTC held on multisig address are not yours. They belong to you and your parnter. To get BCH from this address you either need the signature from him.

I believe that i am the sole owner, as i can access my private keys, I may have worded something incorrectly. I am able to retrieve the unspent inputs from my address in a coinb.in transaction, but when i put in the 36 character coinomi address and click submit, it says One or more input or output is invalid.
I had spaces in the address like a newb, i am now looking at this
The transaction below has been generated and encoded. It can be broadcasted once it has been signed.


text:
How to configure multiple miners on a single network laptop/router?
I have 2 S9's, a router and laptop.
Do the S9's have separate IP addresses or just one network IP for both miners? I realize this sounds stupid, however, I cant figure out how to apply 2 IP addresses to the Bitmain s/w set up. All the set up examples only show 1 miner.


text:
how many unique bitcoins address can be generated in one address pattern
Example address prefix given below

12cgpRC5r7zakGBfRGf5RQfGCgTnp7K1Yb
12cgpFkDMJXdwck9YHrrFsWP8PgxXjtBS7
12cgpcjw2628NPAPMvzSWF9Vh2tcUJrpAa
12cgpDmDJnugoRHeAfief7KSiUFvNPF5MY
12cgpz1PwVesaKArAR53W3owQy32XKuuxT

So first 5 letters are common prefix for all address 12cgp

Wouldn't this be something like 2^(160 - 4)( custom char vanity) = 2^156, although these aren't compressed... Not sure how it would work in that case.. 2^(34 - 4)?

So How many million address

(2^(34-5)) / (2^(33-4)), my mistake. I still don't think this is correct though.

Essentially infinite for most purposes.

So there no end for Single address
e.g my name bitcoin will be infinite, no one can crack it or regenerate my same pattern
1Sturtxxxxxxxxxx can be infinite


text:
Repurposing old FPGAs
So, I have a couple of BTC mining FPGAs lying around from the earlier days when they were worth running (specifically a BPMC Red Fury and an ASICMiner Block Erupter). I'm wondering if these can be used to mine any other cryptocurrencies that might be a little more profitable these days. Any tips would be appreciated!

Those are ASIC miners, not FPGA.
They can mine BTC and clones, but nothing else.


text:
How to develop and then sell my own Bitcoin Hardware Wallet?
Okay so basically I have a good idea for a bitcoin hardware wallet, i'm just looking for information on how to go about creating it?
Do I need to create my own programs/programming for literally everything? Are there open source type things I can use? Would it be illegal to use another wallets programming or whatever? I'm just really confused as to how all of this works out. I'm not the engineer involved with the product, I'm on the finance and business side of things. So forgive me if I sound dumb! Basically, what all can I use that currently exists to make this process as simple as possible without getting any law suits lol. Thanks so much!

If you have an engineer on the project, it might be better to ask them because they'll know the specifics of what you are trying to do :) as it stands, you're asking too many questions here, please try to limit posts to on more specific question each

Well he's an amateur and not experienced with this type of thing at all. I'm just trying to figure out what exactly goes into creating a hardware wallet, like the ledger nano. Sorry my bad im on somewhat of a rampage right now because I had a great idea randomly come to me.

The way you go about creating hardware is by hiring competent engineers, not by asking it on an online forum.

There's not a lot from a electrical engineering perspective inside a hardware like the Trezor. It's a small microcontroller, a very cheap OLED screen, some miscellaneous buttons and connectors. The entire bill of materials is likely under $10 USD for per unit.

The difficulty comes from the software and integrity perspective. You've got to ensure that the software doesn't lose other people's money, that it protects in the ways it intends to, and resists tampering. The hardware should be able to be produced with some confidence that the software written to the devices is secure, that nobody can replace them in transit with identical, but malicious devices. You've got to be sure nobody engineering the devices has their own backdoors to steal money from the device, that there's not ghost runs being made by a producer.
If there's a large theft relating to hardware you've produced, you'll be the one immediately blamed as responsible for backdooring them, so this is an existential threat for the producer if they get it wrong. Are you willing to take this personal risk? Most people would not agree the benefits outweigh the costs, if producing secure hardware seems like a easy idea you've probably not considered all the modes of failure.


text:
parsing bitcoin input and output addresses from scripts
can someone walk me through the process of combining script inputs and outputs to reveal the base58 encoded input and output addresses. take for example, block 728. this has two raw script inputs:
493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

and

493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01

the first byte of each (49 hex = 73 dec) is the instruction to push 73 bytes onto the stack. according to the wiki each of these input scripts consists of a signature and a public key.
the raw output script is
76a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac

which translates to the instructions
OP_DUP OP_HASH160 OP_PUSHDATA0(20 bytes) 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

so given this information, how can i extract input addresses (as shown in blockexplorer.com)? is this even possible?
1Miuw7ifaTYY5qrzKYFcTDiojSFxRfAqwP and 18KrJNtPVu6LWRNPQReqF29iFm7vDhirMk

and output address
12higDjoCCNXSA95xZMWUdPvXNmkAduhWv

the output address is derived solely from the output script starting from step 4 in the wiki like so:
first add leading zeros:
0012ab8dc588ca9d5787dde7eb29569da63c3a238c

then hash with sha256 (if you look in the wiki this is actually part of the OP_HASH160 operation) to give:
e158c4be10913422dadcf1c36843020ebb3ffe9d0cb13fb9e8c0a564a53c7832

then hashed with sha256 again (the wiki is wrong here - it says to use ripemd160, but actually sha256 is required again) to give:
96bf1d277213bbcd91145138e4c7ad8dcd6e1de1c39884fcbc1f5a6d4d7aee93

then grab the first 4 bytes of this result (96bf1d27) and stick them on the end of the original hash160 public key with leading zeros:
0012ab8dc588ca9d5787dde7eb29569da63c3a238c96bf1d27

convert to decimal:
457790304922245030616719694560989441716273193824169172263

base58 encode to give:
2higDjoCCNXSA95xZMWUdPvXNmkAduhWv

and stick a 1 in front of it all to get the bitcoin output address:
12higDjoCCNXSA95xZMWUdPvXNmkAduhWv

now to figure out how to get the input addresses...
thanks to this answer, we can see that both the signatures are der encoded in the following format:

0x30: a header byte indicating a compound structure
a 1-byte length descriptor for all what follows
0x02: a header byte indicating an integer
a 1-byte length descriptor for the r value
the r coordinate, as a big-endian integer
0x02: a header byte indicating an integer
a 1-byte length descriptor for the s value
the s coordinate, as a big-endian integer
a hashtype byte

so, decoding the raw script signatures:
493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

0x49 = OP_PUSHDATA0 - push 73 bytes onto the stack (script command not part of the signature value)
0x30 = header byte
0x46 = length descriptor (70 bytes)
0x02 = header byte
0x21 = r value length descriptor (33 bytes)
00e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b the r coordinate as a big endian integer
0x02 = header byte
0x21 = s value length descriptor (33 bytes)
00b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d the s coordinate as a big endian integer
0x01 = hashtype byte

and the second raw signature has the same format too:
493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01

0x49 = OP_PUSHDATA0 - push 73 bytes onto the stack (script command not part of the signature value)
0x30 = header byte
0x46 = length descriptor (70 bytes)
0x02 = header byte
0x21 = r value length descriptor (33 bytes)
00a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3 the r coordinate as a big endian integer
0x02 = header byte
0x21 = s value length descriptor (33 bytes)
00911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf the s coordinate as a big endian integer
0x01 = hashtype byte

so this confirms that the signature values in the transaction inputs actually do not contain public keys at all. the input addresses actually come from the previous transaction outputs which can be identified through the input hash and input index in the current tx.

this may provide a method of getting the public key from the signature alone https://github.com/nanotube/supybot-bitcoin-marketmonitor/blob/master/GPG/local/bitcoinsig.py

also, this shows how the signature is created http://bitcoin.stackexchange.com/a/5241/2116

Great answer. Wish I could up vote more.

my solution was, that I passed the hex string to:
    def publicKeyDecode(pub):
            hash1 = hashlib.sha256(binascii.unhexlify(pub))
            hash2 = hashlib.new('ripemd160', hash1.digest())
            padded = (b'\x00') + hash2.digest()
            hash3 = hashlib.sha256(padded)
            hash4 = hashlib.sha256(hash3.digest())
            padded += hash4.digest()[:4]
            return base58.b58encode(padded)

had to use sha256 instead of ripemd160 to get the correct address

Had to comment out the first line (pub = pub[2:-2]) to work with the public key (0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352) on the wiki (https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)

Everything depends on the script itself. because it is a program. so you have to interpret it on your own. The above solution was a standard script decoding. Someone edited it, so its not correct for all scripts.

Here's a python3+ implementation for @mulllhausen's answer on parsing the Bitcoin address from the P2PKH script:
import binascii
import hashlib
import base58

def P2PKHToAddress(pkscript, istestnet=False):
    pub = pkscript[6:-4] # get pkhash, inbetween first 3 bytes and last 2 bytes
    p = '00' + pub # prefix with 00 if it's mainnet
    if istestnet:
        p = '6F' + pub # prefix with 0F if it's testnet
    h1 = hashlib.sha256(binascii.unhexlify(p))
    h2 = hashlib.new('sha256', h1.digest())
    h3 = h2.hexdigest()
    a = h3[0:8] # first 4 bytes
    c = p + a # add first 4 bytes to beginning of pkhash
    d = int(c, 16) # string to decimal
    b = d.to_bytes((d.bit_length() + 7) // 8, 'big') # decimal to bytes
    address = base58.b58encode(b) # bytes to base58
    if not istestnet:
        address = '1' + address # prefix with 1 if it's mainnet
    return address

print(P2PKHToAddress("76a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac")) # 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv

authors: จีรัฐติกุล ศรีสุวรรณ

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


text:
upgrading to bitcoin 0.10.2 fails
i am attempting to upgrade my bitcoin client on debian wheezy. i have been following the docs for this version and i installed berkley db to ${BITCOIN_ROOT}/db4 as directed. that went fine, but now when i run ./configure it says the wrong version of berkleydb is installed:
checking whether C++ compiler accepts -fvisibility=hidden... yes
checking for Berkeley DB C++ headers... default
configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore or --disable-wallet to disable wallet functionality)

i also found that autogen.sh does not exist in the bitcoin root dir so i was unable to run it as per the instructions.
i already have berkley db 5 installed:
$ dpkg -l | grep db5
ii  db5.1-util                                   5.1.29-5                           amd64        Berkeley v5.1 Database Utilities
ii  libdb5.1:amd64                               5.1.29-5                           amd64        Berkeley v5.1 Database Libraries [runtime]
ii  libdb5.1++:amd64                             5.1.29-5                           amd64        Berkeley v5.1 Database Libraries for C++ [runtime]
ii  libdb5.1++-dev                               5.1.29-5                           amd64        Berkeley v5.1 Database Libraries for C++ [development]
ii  libdb5.1-dev                                 5.1.29-5                           amd64        Berkeley v5.1 Database Libraries [development]
ii  libdb5.1-java                                5.1.29-5                           all          Berkeley v5.1 Database Libraries for Java
ii  libdb5.1-java-jni:amd64                      5.1.29-5                           amd64        Berkeley v5.1 Database Libraries for Java
ii  libkdb5-6:amd64                              1.10.1+dfsg-5+deb7u2               amd64        MIT Kerberos runtime libraries - Kerberos database
ii  libsybdb5:amd64                              0.91-2+deb7u1                      amd64        libraries for connecting to MS SQL and Sybase SQL servers

i don't want to remove db5 because other programs i rely on are using it:
 $ apt-cache rdepends db5.1-util
db5.1-util
Reverse Depends:
  subversion
    db5.1-util:i386
  subversion
    db5.1-util:i386
  libapache2-svn
    db5.1-util:i386

how can i get bitcoin to install with berkley db 4.8 when 5.1 is already installed elsewhere?

To allow compatibility of your wallet.dat file with other bitcoind installations, it's strongly recommended to use bdb 4.8.
Nevertheless, you can disable the db4.8 check by adding --with-incompatible-bdb during configure.
Better would be to manually install berkley db 4.8 in a isolated path and compile bitcoin-core with something similar to:
CPPFLAGS="$CPPFLAGS -I<your-bdb4.8-path>/include"
LIBS="$LIBS -L<your-bdb4.8-path>/lib"

But this would probably require some makefile tweaking.

thanks! i have already installed berkley db 4.8 under ${BITCOIN_ROOT}/db4 (i followed the instructions in docs/builld-unix.md) i will try and compile bitcoin-core with the flags you suggest. if i have problems i will update the op.

nope - its still coming up with the same errors when i run ./configure even with CPPFLAGS="$CPPFLAGS -I${BITCOIN_ROOT}/db4/include" and with LIBS="$LIBS -L${BITCOIN_ROOT}/db4/lib"

If you have troubles using different include/ lib/ dirs for bdb you might try --with-incompatible-bdb and take the risk of not being able to use your wallet on bitcoin-core installations with bdb4.8.

ya i did that :) i can always import my private keys into other wallets so its no big problem for me


text:
I bought a bitcoin before my client sychronization was finished. Will I get the coin?
I bought a bitcoin before my client synchronization was finished.
Will this stop me from getting the coin or will it just come later when the wallet is synchronized?

No, it will not matter.  Sync only affects the readiness of your client.  The purchase is reflected on the public blockchain, which has nothing to do with whether your client is ready or not.

Oh that's a relief, so I will just have to wait then I guess? Thanks for you help Harold it's most appreciated :)

Thank you also for teh reply Pyramid, I have only just seen that answer. And yes it was not sychonized with network yet.

You can use a thin client like Multibit, and the synchronization is much faster because it doesn't download the whole blockchain.  But that doesn't mean that the verification of transactions will be faster.  Verifications are done on the public blockchain, and have nothing to do with your client.

What @HaroldNaparst said. But remember to keep your wallet file (or some other representation of the private key(s)) because you need that to get the coins in the wallet.


text:
Is bitcoin mining itself compromising the security of SHA256
Following good scientific practice I propose a Theory/Hypothesis and now ask you to test it.
Initially this is a "thought" experiment but may progress to real testing depending on your thoughts. Back to the initial question first; My question: Is bitcoin mining itself compromising the security of SHA256?
Possible answers:

Yes (maybe qualified by "in some way" ,etc).
No (Not at all because...xxx ,Not unless...YYY).
Maybe (??).

The hypothesis is this:
SHA256 is extensively used in many applications (including Bitcoin).
It would be of great advantage for many persons, organisations and (not least) governments/military/NSA (etc) to be able to "crack" it.
Cryptographic experts have so far failed to crack SHA256 and only a small number of defects (possible collision scenarios) have been declared which although reducing the theoretical security (of a brute force attack) do not compromise SHA256 in practical use.
SHA256 look up tables exist for e.g. dictionary attacks and are very fast to use particularly for shorter passwords (<8 character). To extend the possibility of using look up tables for longer inputs a huge amount of computing power is needed to run many Terra inputs through SHA256.
This power is impractical to set up and run (cost of hardware, manpower, etc) and if it were set up e.g. by NSA using a super-computer it existence would be apparent and therefore usage of SHA256 would decline as it would be assumed that they wouldn't do that unless they thought they would get a result so users of SHA256 would migrate to a more secure system (e.g. SHA3 series). Therefore what NSA (or whoever) need is a "covert" way of "testing/running" SHA256 and gathering the results.
Is bitcoin mining with its daily 4000+ TH/s power, funded and manned entirely by users of the hardware hoping to gain Bitcoins (and hoping they are worth some real $$) really performing a service for the NSA (or someone) and effectively "hiding in plain sight"?
Methods of testing this hypothesis are invited.

Related question: Has mining created enough technology to solve SHA256, such as ASICs, that SHA256 is weaker for other purposes than it would be otherwise? In other words, can the NSA, its foreign counterparts and other hackers now break some encryption more easily than before the advent of SHA256 ASICs?

This should maybe be posted as a separate question and linked.

Thanks Random Walker for putting a different spin on my question. Certainly there is now a lot of SHA256 specific hardware about in the hands of bitcoin miners and the development of ASIC for SHA256 has been enhanced. Who knows how much of the ASIC chips have been sold "elsewhere" (other than mining rig manufacture) ? It certainly helps offset the developement cost if we have a real world customer base (miners) as well as XXX code cracking company.

possible duplicate http://bitcoin.stackexchange.com/questions/9320/can-the-bitcoin-network-be-used-for-cracking

With a look up table you can avoid calculating the hash of a given input twice. Indeed, the block chain can be considered as a giant look up table, but one with very special forms of inputs: It links blocks and transactions to their hashes.
Though, why should someone choose a transaction or block as her password? Further, why would an attacker even try to look up a hash of a password in the block chain? He would have to assume in advance that the password is a transaction or a block (don't forget that even looking something up consumes some resources).

True, but the target has a very specific format starting with many 0000 so you are also testing hash inputs to create a specific subset of possible outputs. I'm not suggesting the results of bitcoin mining hashes are the raw data for the lookup table but are useful in creating a bigger lookup table. Generally used passwords are often under 12 characters length so SHA256 hashing of 2 different short passwords has a huge amount of the same (blank characters) input c.f. target 000000s.

It would reduce the amount of work you would need to make a complete table if that is what you're trying to do. How useful this part is itself is a good question.

Have a look at crackstation.net. They have a partial lookup table for SHA256 for short passwords, it works and is fast.

Theoretical answer: yes and no.
Practical answer: not at all.

SHA-2, or specifically SHA-256, is a good hashing algorithm as far as we know. It has all the properties desired and there are no real attacks on it. It has already been battle-tested a lot in the past years. That Bitcoin uses SHA-256 makes it an even more interesting algorithm to try to crack (there is 'money' behind it now), and with all the ASIC producers popping up it becomes less work to also create ASICs that try to crack passwords hashed with this.
So with all the extra attention SHA-256 gets, it is now more likely that flaws are found rather sooner than later. However, SHA-2 is a very widely used algorithm as it is, regardless of its use in Bitcoin. If there were any great and obvious flaws, they would have been found already.
It can be compared with RSA, which now powers many of today's financial transactions and encrypted connections. That too draws a lot of attention to it, but good algorithms don't become bad just because they are in the picture.
So while all the extra ASIC production for Bitcoin mining may also provide for better password cracking tools and brings more people to look at the algorithm, this is no practical problem. Also, you should not use SHA-2 directly as a password hashing mechanism anyway. For that, see this question: https://security.stackexchange.com/q/211/10863
Edit: Read your question more thoroughly now instead of responding to the title.

Is bitcoin mining with its daily 4000+ TH/s power, funded and manned entirely by users of the hardware hoping to gain Bitcoins (and hoping they are worth some real $$) really performing a service for the NSA (or someone) and effectively "hiding in plain sight"?

No. That's just tinfoil hattery and not even worth the "thought experiment" (nice try, conspiracy theorist) since it can readily be disproved. See other answers about what we're hashing (hint: we're not finding hashes for actual passwords or other purposes).

Regardless of any conspiracy theory. The fact that ASIC machines are now commercially available (both hardware and completed systems) makes it easier for any agency to buy them and use them. In my opinion, this does compromise SHA-256.

Yes, it makes a sha256 has easier to guess, by buying dedicated ASICS.   Scrypt is a better hash because you can tweak the ram requirement up to the point where ASICs are not practical.

authors: ทรรศนีย์ มิลภมร


text:
How to communicate between Java and bitcoind?
I am having problems communicating between Java and bitcoind - every JSON RPC library I try has some issues. Can anyone provide a working implementation of even the most basic JSON RPC communication between Java and bitcoind ?

There's a bitcoin library for java... That could be why few people are working on a JSON RPC for java.

Here's an early experimental client I had played around with a while back. It supports getInfo, getBalance and getNewAddress, and can easily be expanded. In order to run it, the credentials for your local bitcoind have to match the values in the client class:
httpclient.getCredentialsProvider().setCredentials(new AuthScope("localhost", 8332),
                    new UsernamePasswordCredentials("btc", "123"));

Feel free to use this code in any way, but understand that it's only 5 minutes of work on a start, not a realistic client implementation. Hope it helps you generate some ideas!

I like this solution a lot, the only issue is that the first call on this client takes very long. A 'getrawtransaction' call on my laptop takes 288 ms suing this http client while running a process from Java takes ~ 5 ms. However, this client is more efficient in the long run taking about 4 ms on average for all other calls. I tried to speed it up by trying to use cookie authentification but was not able... Solutions to this problem are welcome!

You are also very welcome to try out https://github.com/clanie/bitcoind-client - it is in early development, but already supports almost all the methods provided by bitcoind.

Because this seems like a collection of links, I will just add another one:
https://github.com/priiduneemre/btcd-cli4j

I had the same issue and created an implementation here: https://github.com/johannbarbie/BitcoindClient4J

https://github.com/nitinsurana/Litecoin-Bitcoin-RPC-Java-Connector
It uses Htmlunit instead of Apache Http Library, which makes it a bit easy to understand and extend.
I actually wrote & tested it for Litecoin for one of my projects. But it has been extended to support bitcoin and all the RPC methods are available.

Library under Apache Licence:
https://github.com/SulacoSoft/BitcoindConnector4J

Since I could not find working code snippet anywhere, here is a complete working example (in Scala):
First I created a helper object:
import java.net.URL
import java.net.HttpURLConnection
import org.apache.commons.io.IOUtils

object CurlJsonData {
  def curl(url:String, jsonEncodedString:String) = {
    val httpcon = new URL(url).openConnection.asInstanceOf[HttpURLConnection]
    httpcon.setDoOutput(true);
    httpcon.setRequestProperty("Content-Type", "application/json");
    httpcon.setRequestProperty("Accept", "application/json");
    httpcon.setRequestMethod("POST");
    httpcon.connect;

    val outputBytes = jsonEncodedString.getBytes("UTF-8");

    // 'using' method from: https://stackoverflow.com/a/5218279/243233

    using(httpcon.getOutputStream){os =>
      os.write(outputBytes)
    }
    val code = httpcon.getResponseCode
    val isError = code >= 400 && code <= 500
    val resp = using{
      if (isError) httpcon.getErrorStream else httpcon.getInputStream
    }{is =>
      val writer = new StringWriter;
      IOUtils.copy(is, writer, "UTF-8");
      writer.toString;
    }
    httpcon.disconnect
    if (isError) throw new Exception(
      s"Resp code $code. Error: ${resp.take(200)}"
    ) else resp
  }
}

Then, I used it as follows:
import java.net.Authenticator
import java.net.PasswordAuthentication

val rpcuser = "alice";
val rpcpassword = "secret";

Authenticator.setDefault(
  new Authenticator {
    override def getPasswordAuthentication:PasswordAuthentication = {
      new PasswordAuthentication (rpcuser, rpcpassword.toCharArray)
    }
  }
)

CurlJsonData.curl(
  "http://localhost:8332",
  """{"method":"getblockchaininfo","params":[],"id":1,"jsonrpc":"1.0"}"""
)

One of the problems of Java is the verbosity of the language. However, it is also true that the life of the language it is very old in these that.
I fall into the problem to talk with the bitcoin rpc interface for one of my side projects on c-lightning and I was not able to find a clean library that is able to talk also with other rpc interfaces derived from bitcoin core, like litecoin. In addition, I found also a library that is easy like a python library.
My result of designing a library that respect this requirement, it is called lite-bitcoin-rpc and it is available on GitHub https://github.com/clightning4j/lite-bitcoin-rpc
This is an easy library because with gives the possibility to write the JSON wrapper in a Java class and use it to decode the response. The end-user need only to feel a map with parameters and create the Java class where decode the JSON payload received from bitcoin core.
An example can be found in the test directory https://github.com/clightning4j/lite-bitcoin-rpc/tree/main/lib/src/test
and a code example can be
public class LiteBitcoinRPCTest {

  private LiteBitcoinRPC bitcoinRPC;

  public LiteBitcoinRPCTest() {
    this.bitcoinRPC = new LiteBitcoinRPC("sandbox", "sandbox", "http://127.0.0.1:18333/");
  }

  @Test
  public void getBlockchainInfo() {
    try {
      BlockchainInfo info =
          bitcoinRPC.makeBitcoinRequest("getblockchaininfo", BlockchainInfo.class);
      TestCase.assertEquals(info.getChain(), "regtest");
    } catch (Exception e) {
      e.printStackTrace();
      TestCase.fail(e.getLocalizedMessage());
    }
  }

  @Test
  public void estimateFeeRateWithError() {
    Parameters parameters = new Parameters("estimatesmartfee");
    parameters.addParameter("conf_target", 6);
    try {
      BitcoinEstimateFee feee = bitcoinRPC.makeBitcoinRequest(parameters, BitcoinEstimateFee.class);
      TestCase.assertFalse(feee.getErrors().isEmpty());
    } catch (LiteBitcoinRPCException | BitcoinCoreException e) {
      TestCase.fail(e.getMessage());
    }
  }

If Scala is not your thing, here is Jus12's code in Kotlin:
package com.my.blockchainparser

import java.net.Authenticator
import java.net.PasswordAuthentication
import java.net.URL
import java.net.HttpURLConnection

fun main(args: Array<String>) {
    val rpcuser = "user"
    val rpcpassword = "password"
    Authenticator.setDefault(object : Authenticator() {
        override fun getPasswordAuthentication(): PasswordAuthentication {
            return PasswordAuthentication(rpcuser, rpcpassword.toCharArray())
        }
    })

    System.out.println(curl(
            "http://localhost:8332",
            """{"method":"getblockchaininfo","params":[],"id":1,"jsonrpc":"1.0"}"""
    ))
}

fun curl(url:String, jsonEncodedString:String): String {
    val httpcon = URL(url).openConnection() as HttpURLConnection
    httpcon.setDoOutput(true);
    httpcon.setRequestProperty("Content-Type", "application/json");
    httpcon.setRequestProperty("Accept", "application/json");
    httpcon.setRequestMethod("POST");
    httpcon.connect();

    val outputBytes = jsonEncodedString.toByteArray();

    httpcon.getOutputStream().use {
        it.write(outputBytes)
    }
    val code = httpcon.getResponseCode()
    val isError = code >= 400 && code <= 500
    val text = (if (isError) httpcon.getErrorStream() else httpcon.getInputStream())
            ?.bufferedReader()?.use {
        it.readText()
    } ?: "no connection"
    if (isError) throw Exception(
            "Resp code $code. Error: ${text.take(200)}"
    )
    return text
}


text:
Scenario: disaster splits the Internet into dozens unconnected fragments
Major US cities restore connectivity locally for a couple of days, but the internet islands are separated (or have very poor interconnectivity).  Two days later, connectivity is restored resulting in, say 50 separate blockchains full of transactions.  NYC leads the pack with 5% of all transactions and is the dominant chain.  How do we reconcile 95% of the transactions (from 49 chains, less than 5% each) ?  Would anyone in their right mind use bitcoin in times of trouble?

That's a very good question.

possible duplicate of What would happen if a portion of the Bitcoin network was separated from the rest of the network?

possible duplicate of Countrywide Internet isolation, inevitable fork

An interesting scenario occurs if  severance happens when the network very close to a 2016 block.
When mined 2016 block in most powerfully mined network fragment, a new hash rate is computed there -- likely 4x easier than current hash rate.  Thus instead of 1 block per 200 minutes (at 5% mining power local to network shard) 1 block per 50 minutes will get mined. The Bitcoin network works locally -- sort of -- adding many blocks before connectivity is restored. Confirmations will require 5x minutes, not 20x minutes.
Now, connectivity is restored.  Local chains where the 2016 block was solved are much longer.  One of them wins instantly.  The whole Bitcoin network accepts lower difficulty and starts operating with a lower hash difficulty until the next 2016 block is solved.  It takes blocks 2.5 minutes to solve instead of 10, and it takes nodes 4 times the normal bandwidth to keep pace.
But miners local to the network fragment containing  the greatest mining power win.  95% of competition is eliminated, so mining gets 4x easier per block.  Blocks take longer, but the earned bitcoin payout per spent mining effort is quadrupled until connectivity is
 restored.
Difficult imagining though anyone with so much to gain in quadrupled mining payout, that they are willing to cause a global catastrophe.

Most merchants accepting Bitcoin transactions require six confirmations, so if there is no connectivity then, of course, there would not be any confirmations.
So while continuous connectivity isn't required to use bitcoin in commerce, at least sporadic connectivity is.
For merchants who accept on 0/unconfirmed (e.g., retail), the rely on protection from the network to know of a race attack.  Without connectivity, that protection is gone and the merchant is vulnerable.  If the customer can be trusted, then a transaction on 0/unconfirmed can be accepted even without continuous connectivity.
For when extended outages occur, there wouldn't be multiple blockchains as there's no chance some isolated node (or region of connected nodes) would have the hashing capacity to make it to even one or two confirmations nonetheless six confirmations.  So there's no isolated forking issues to be concerned about.
Futher discussion on the suitability of bitcoin on an "disconnected island" occurs here:

http://bitcointalk.org/index.php?topic=106302.0

"nonetheless six confirmations." If my region has 3% of the network hashpower, then I can get to 6 confirmations within 1.5 days. Not that I would, though, because all my work is going to be gone when NYC comes back online.

50 different views of the current state of the network develop. I'm going to assume that 5% of mining power is also in NYC. What happens is that when the network problems are lifted, the NYC blockchain instantly "wins". Every other miner loses all of their work. Consequently, there is zero reason to mine unless you will win the race.
However, a funny thing happens. People in every non-dominant region have an incentive to connect to a well-informed region to find out about new blocks. A satellite connection of about 10 Kbps is enough to keep up with the network. Once they have mined their block, they might as well tell local merchants about it, keeping them in sync too.
But let's suppose for a moment that satellite internet is entirely out of the question. Would a station wagon full of tapes driving down the highway be enough to keep your miner in sync? Not really, unless you're very close to a well-informed node. However, it might be worth it to somebody who wanted to get their transactions in or check on their transactions.

Would anyone in their right mind use bitcoin in times of trouble?

That depends on the disaster. If this is a freak series of coincidences that caused all of these redundant systems to stop working all at once, then I think everybody is going to wait. What's harder, trying to figure out whether you could get scammed, or closing shop for 24 hours?
On the other hand, if this were an alien invasion that was here to stay, I think people would continue to use bitcoin; however, they'd fall back more often on trust based systems. They might refuse to deal with new customers unless they were recommended by an old customer. Occasional station wagons would keep merchants reasonably in sync.

I can see a close system being very helpful for local businesses. Imagine I want to go to dinner. After eating I pay for it through a terminal connected to the rest of the offline system the restaurant uses as they do now when inputting order, discount's etc. Go to the grocery store and pay for your food at the checkout, (closed system) Yeah, it does nothing for purchasing online, but would it be that difficult to go down to the municipal building to pay your water bill?

Your question shows a fundamental lack of understanding about how the BitCoin protocol ensures valid, trustworthy transaction history.


text:
What mathematical property links the Armory chain to the public/private keys?
According to the Armory site the Public Keys needed for the Bitcoin addresses can be generated without having access to the Private Keys, which ideally are stored on a completely different computer.
What mathematical property allows public keys to be generated without having the matching private keys? I take it they are seeded by the chain code somehow, so the chain code is the stored in the watch only copy of the wallet, while the chain code + root key make up the private wallet, right?

Could you please give a link to the page you're referring to, and name the section of the page the comment is in?

ECDSA can be thought of as a special form of mathematics where division is, for all practical purposes, impossible. Public keys are formed from private keys by multiplication -- the public key is multiplied by the generator G. Because of the properties of multiplication, new public keys can be generated by an entity that doesn't know the corresponding private key.
First, a master public/private keypair is generated (master, G(master)). The master private key, master, is stored securely. The master public key, G(master)) is used to generate new public keys as follows:

A new public/private key pair is generated. X, G(X)
The public key is added to the master public key. G(X) + G(master)
This new public key can now be used.

To generate the corresponding private key, the private key generated in step 1 is added to the master private key to form X + master. This works as the private key becauseG(X + Master) = G(X) + G(master) (distributive property of multiplication). Thus the public key corresponding to the sum of the two private keys is the same as the sum of the two public keys.
You can pretty easily show that producing X + master without knowing master or forging a signature of G(X + master) with only X and G(master) is as difficult as breaking ECDSA itself. So this scheme is as secure as any other method of using ECDSA.

In the example you give, X is some sort of incrementing value, so that the two wallet are generating the same series of Xs?

It can be done that way. One way is to derive X from G(master) by appending an integer to it and then hashing.


text:
Will I lose payments on a mining share in the time it takes to sync?
I bought a mining share a couple months ago from Bitcoop, downloaded the wallet that they suggested, and the wallet has taken this long to sync. The first mining payout was a few weeks ago.
Will I get that payment or is it lost?

You will get that payment. Your wallet does not need to be online or synchronized to receive funds, only to do anything with them. (I'm assuming you're using Bitcoin-qt or something similar, I don't know what that vendor recommended or what you've done.)
However, the client shouldn't take months to sync, so this could indicate there is some problem.


text:
Why does Bitcoin make my computer lag/freeze?
Whenever I run bitcoin, my computer (Dell E4200 running Ubuntu 12.04, with AwesomeWM) lags quite heavily.
It will operate normally for 10-15 seconds, then 'freeze' for 10 to 15 seconds, during which time keyboard and mouse input seems not to register. Some actions are more affected than others. Chrome won't output keystokes in this textarea during such a lag, but I can change tabs freely. All the keystrokes show when the freeze ends.
I am running bitcoin-qt from this repository: https://launchpad.net/~bitcoin/+archive/bitcoin
I installed it with sudo apt-get install bitcoin-qt
Version shown during install:
Unpacking bitcoin-qt (from .../bitcoin-qt_0.6.2-precise0_amd64.deb) ...
I had the same issue when I was running Ubuntu Unity, and the 'original' bitcoin client.
My client is currently synchronizing with the network.
My total CPU usage is between 20-60%, with occasional spikes to 90+%.
Memory usage is steady at ~60%, and swap is ~5%.
Any clues to help me diagnose / solve this issue?
Thank you.

Are you running on an encrypted filesystem?

Yes, my home folder is encrypted.

Is this while downloading the blockchain? Or do you already have all the blocks?

It's currently download the blockchain.

While downloading the blockchain, it's got effectively an unlimited amount of work to do that it's trying to do as quickly as possible. I'd recommend doing that when you have nothing else to do. (Overnight, or over many nights if needed.) Then it should be able to stay synched without high load.

When you use the Bitcoin client for the first time, the client has to download the whole Bitcoin blockchain from the network. This can really (really!) take a while and because it is stored in your homefolder and therefore has to be encrypted, this take some CPU power as well.
Apart from this, while your client runs, it helps verifying new transactions offered to the network, just like every connected Bitcoin client does, these calculations can take CPU power as well.
What CPU does your machine have?
You can try to use clients like MultiBit that do not download the whole blockchain, but only the part that is relevant to your coins.

I don't think there's compression going on.  What takes the CPU time is verifying the signatures on all transactions newer than the newest snapshot.

I was quite sure I read somewhere that the older parts of the blockchain were stored is a compressed way. Although doing some search I cannot find the source I got this from.
If it would not be true, I'm sorry, but I really thought it was true :)

I believe it's stored as a merkle tree. Thanks for your answer. Perhaps the problem will cease when the whole chain has finished downloading.

@StevenRoose You may have read about 'pruning' of the blockchain to remove transactions whos outputs have already been spent.  This has been proposed as a way of saving disk space, but as far as I know it hasn't been implemented yet.

@ChrisMoose No actually I definitely read about compression. Weird, because indeed everywhere I look, it's never mentioned. Will delete it from the answer.

You indicated you are on an ecrypted filesystem.
This makes sense due to the BDB log files including sensitive data:

Does the BerkeleyDB-based wallet.dat implementation leak private key data?

There is no method currently that allows the public data to be in one location and the private date to be kept in another (presumably, on an ecrypted filesystem).  See Issue #791 for this:

http://github.com/bitcoin/bitcoin/issues/791

So perhaps a solution is to use a non-encrypted filesystem until you have the blockchain brought up to date.  Or throw hardware at the problem so it is less noticeable.

Although bitcoin is a heavy CPU user, that shouldn't cause freeze-ups of the sort you describe. They are usually caused by driver code. Since the only devices bitcoin uses are the network and the disk, and it isn't a heavier user of the network than many other applications, I would look for disk problems.  Bad disk blocks cause freezes. Check for errors in the system log, or run Disk Utility and look at the "SMART Status".

In my case, the first time running bitcoin-qt on Kubuntu Linux 12.04, on an X86_64 machine, synchronising the block chain is consuming 3.57 GB of RAM @ about %75 complete, but only using about %20 average CPU on a Phenom 9950. I had to start shutting down a few services (apache, mysql, etc...) because the swap partitions where getting hit quite heavily and causing my GUI to freeze up for long periods.


text:
Receiving bitcoins without open client?
If I am planning to accept bitcoins, does my client need to be running? Can I simply give out my public key and open the client later to receive? Does it depend on the client (I use MultiBit)? Furthermore, if I send bitcoins, do I need to keep the client open for the receiver to receive their payment, or are they all set to receive as soon as their balance (not available balance) goes up?

I have the same question, since it doesn't need the client be open, why it takes so long to confirm? I have started a transaction at 1:00 nignight, when I get up at 6:00, it still didn't finish! they say a transaction need 6 confirm witch cost about 1,5 hours.

To accept a Bitcoin transaction, you only need to give out a hash of the public key also known as the Bitcoin address. That said, if you are a merchant then the recommended practice is to give out a new bitcoin address for every transaction to make it easier to distinguish between orders from different people.
Assuming that whatever Bitcoin client you choose is honest, then it doesn't matter what client you use. Underneath it would be the same message broadcasted by the Bitcoin network. You don't need to have a client open at all times to send or receive payment, but if you use Bitcoin-Qt then you would need to have an up-to-date blockchain database in order for client to scan through the blockchain to show all received/sent transactions and display the correct balance.

Bicoins are "received" to all connected nodes, not just to your node.  So no, your client does not need to be connected to receive.
To send a transaction, the transaction needs to be broadcast to peers that are connected.  Generally, this will happen in seconds but if your network happened to hiccup or it had only connected to non-compliant peers that didn't relay your transaction (perhaps by rogue nodes, for instance) or for whatever reason, then your client will re-broadcast the transaction after a period of time has passed.  If the client isn't still running, then the re-broadcast won't happen.
There are services that can show if a transaction was successfully broadcast.  One is BlockChain.info:

http://www.BlockChain.info

Once a transaction is successfully broadcast, then the work of the client is done.  It can be closed, without needing to wait for any confirmations to occur.


text:
How big is the blockchain on disk as of 5th July 2012?
I just started Bitcoin-qt for the first time, and it is syncing. How much space does the blockchain take up? I have my drive heavily partitioned, and my /home partition (linux mint) is only about 20GB. Does anyone have a size accurate within 100MB?

At the moment, it's about 2.6GB, but it will be growing with time.
You can try looking into using an eWallet or some lightweight clients if you are tight on the disc space. Their space requirement is minimal in comparison, but the security model they offer is different. The lightweight clients are developed by other people than the core Bitcoin team, so you have to know that you can trust them (haven't yet heard about a case of the lightweight clients being malicious). With the eWallets you put the security of your money in the hands of the third party and their server. There have been incidents of people losing a lot of coins because of this (like MyBitcoin), but if ran well and by trustworthy people, your Bitcoins can be more secure than on your computer.

But you can only mine with Bitcoin-qt or the daemon equivalent, right?

No, not exactly. You don't need your own client running to mine. You just need to point your mining software at a pool. You do however need the daemon if you want to solo-mine.

Saying that an eWallet offers less security is wrong. It's a different security instead. Keeping your wallet unencrypted on your disk, vs. keeping it properly encrypted in a remote server?

@Lohoris I said that they CAN offer less security, it doesn't mean that they do. One or either way, I clarified my statement.

Much better now!

This thread in bitcointalk was posted on June 30th 2012 and discusses a graph of the size of the blockchain over time and predicts it into the future. Currently, the graph looks like this:

So in ~50 years, the storage will be more important for "pro-miners" than the GPU, it would seem.

This doesn't include the block headers or the index, so roughly multiply by oh, say 1.25 to get in the right ballpark.

http://blockchain.info/charts/blocks-size

@lucase.62, the storage issue is likely to be a temporary one for end users. More info here: http://bitcoin.stackexchange.com/q/478/516 and on general scalability here: https://en.bitcoin.it/wiki/Scalability

@lucase.62 Not really, just think back 50 years back and try remembering how big hard drives were available then in comparison to now? http://en.wikipedia.org/wiki/File:Hard_drive_capacity_over_time.png Pretty insignificant in comparison. The block chain probably won't outgrow cheap storage capacities in a long time.

Here are the current file sizes:
$ date
Thu Jul  5 00:21:12 PDT 2012
$ ls -l blk*
-rw------- 1 chris chris 2035532730 Jul  5 00:13 blk0001.dat
-rw------- 1 chris chris  699731968 Jul  5 00:13 blkindex.dat
$ bitcoind getblockcount
187613

and to give an idea of daily growth, here it is around 25 hours later:
$ date
Fri Jul  6 01:33:04 PDT 2012
$ ls -l blk*
-rw------- 1 chris chris 2046730806 Jul  6 01:32 blk0001.dat
-rw------- 1 chris chris  703234048 Jul  6 01:32 blkindex.dat
$ bitcoind getblockcount
187757

Protip:
ls -h, --human-readable: with -l, print sizes in human readable format (e.g., 4M 2G)


text:
Does the percentage of fluctuation remain the same regardless of the value in all wallets?
This was initially going to reference this question here
I, as well, have $10 bitcoin in my wallet, I notice the value does fluctuate. However, will the value fluctuate the same in a $100 wallet, as if it were $10?
In other words, my $10 is now $11.72, does that mean the value of a $100 wallet will be $101.72, or will the value be much higher?

As per one of the answers for the question you referenced, it does depend on how you express value.
Your example of $10 increasing to $11.72 is an increase in value of 17.2%
If you ignored any transaction fees, and any effects of market depth, then it would be reasonable to assume that $100 with the same percentage increase of 17.2% would become worth $117.20.
If wallet software took into account the cost of transaction fees, then a higher balance may justify a bigger percentage increase, based on the anticipated transaction fees for spending the funds.

You rock, that cleared up any other questions I may have!

if your bitcoin equivalent value of 10$ became 11.72$, then 100$ will be 10 times the value - at 117.20 (not 101.72 - I assume this was just a typo).

I initially edited the question, but then reverted it in case it's not a typo


text:
During transaction getting 'Insufficient funds' message from Bitcoin core
I am trying to make sendbtc transaction using bitcoin rpc call but getting failed message "Insufficient Funds" from bitcoin core.
In addition, once I am trying to make transaction for small amount like below .5 BTC, that transaction successfully done. But for higher value, bitcoin is sending a message "Insufficient funds".
Please suggest me what can I do to make higher value transaction.

we are using the following command sendfrom "emdad" "19aVGaNfWdZYMgCpMx7tKDXrxeddysddd"

The account system is deprecated because it has behavior which most people find unexpected, leading to a lot of confusion. Despite the fact that getbalance "emdad" returns 10.44 BTC, you do not actually have that much BTC in the wallet, you only have the 0.2692 BTC which getbalance and/or getwalletinfo showed. That is why you cannot spend more than 0.27 BTC, because you do not have that much.
Note, transactions need to pay a fee too, so you can't send the entire wallet balance as a transaction output, you would only be able to send slightly less than the amount given.


text:
How do I make my own Hyperstake coin
So ive forked the code but seems to be connected to the old coin stuff.
What I am looking to do is fork their code and create my own coin! I know that I need to make a node but I can't find any process that shows me how to create my own coin.
Please help

What the hell is hyperstake?

I remember reading something about this a while ago (for a different altcoin), and it said you need at least 2 nodes configured to communicate with each other. Maybe that helps? It may differ depending on which altcoin codebase you start with though.

Yes that def pointed me into the right direction! Anyone know how to setup checkpoint to send a certain amount of the moneysupply to certain addresses as soon as I run the node?

you may want to disable dns seeds
use connect=<ip_of_other_node>
instead addnode=<ip_of_other_node> in you coin.conf file.

did you manage to get it working ?

I did but trying to setup a premine for a pos.. Decided to fork blackcoin but no idea how that works yet


text:
How to get bitcoin address of any private key?
calling bitcoin-cli dumpwallet returns wallet private keys and addresses.
Example
L34D2hAS9KBJQzJkHtmNt1bdSJ18cQUvfSnJEqPKH2oUj6sBxvXt 2017-11-23T05:11:13Z reserve=1 # addr=1D2mnuj9qeRAzmw8mjLDciyvqzQiiYZCfE hdkeypath=m/0'/0'/1030'

Importing this private key to wallet using importprivkey command returns null on success.
How to get bitcoin address related to this private key? or is there's any way get this private key details like balance or addresses?

You could use an online wallet like https://blockchain.info/wallet/#/.

Thanks but i'm looking for a solution on bitcoin-core. if you got any idea how blockchain is getting these info it would be great.

the private key is a Private Key WIF Compressed, 52 characters base58, and can be used to convert into (compressed or uncompressed) public keys. These pub keys are usually hex codes, and can be converted into bitcoin addresses: 1D2mnuj9qeRAzmw8mjLDciyvqzQiiYZCfE and 1KWvNZB4Gf2Kars88aGR2cedUb81Q6gZKC. There is no easy way I am aware of to do this in bitcoin client.
Looking at the line you provided, the bitcoin address is behind the comment sign (#), and is part of a HD key, which complicates things even more, if I had to explain it. To understand the whole idea behind keys, you may want to read bitcoin.org or the book af Andreas "Mastering Bitcoin" (online available).
Looking then at e.g. blockchain.info, you can provide the addresses or the keys, and see that there is no value.
Hint: never ever (!) use this key again to transfer values. It has been disclosed, and people are only waiting to snipe the values from this address! - me too :-)

So is it possible to generate more than one address using same private key?

yes. A priv key alone can already generate two pubkeys (compressed and uncompressed). And HD wallets: just a short extract from the book: "HD wallets contain keys derived in a tree structure, such that a  parent  key  can  derive  a  sequence  of  children  keys,  each  of  which  can  derive  a sequence of grandchildren keys, and so on, to an infinite depth".

Thanks for your answer, I would be happy to get this book!

here: http://chimera.labs.oreilly.com/books/1234000001802/ and there is somewhere already the second edition (don't have the link ...)

https://unglueit-files.s3.amazonaws.com/ebf/05db7df4f31840f0a873d6ea14dcc28d.pdf

using PHP and Bitcoin-PHP library, we can do the following to get Bitcoin address of any private key:
        try {
            $master = PrivateKeyFactory::fromWif($key);
        } catch (\Exception $e) {
            echo "Invalid Address";
        }

        $BitcoinAddress = $master->getPublicKey()->getAddress()->getAddress();

        echo $BitcoinAddress;


text:
Change currencies through BitCoin or other Cryptocurrency
I'm from Brazil and I'm going to USA in January, so I need to buy dollars.
Here in Brazil every currency exchange done have to pay a tax that is usually 7%.
But we don't have to pay that tax in cryptocurrency.
So i was wondering if I can do it through Bitcoin or other cryptocurrency.

First I would buy Bitcoin in Brazilian currency to my wallet through any exchange (Real to Bitcoin)
Second I shall sell this Bitcoin in any exchange that accept USA Dollars. (Bitcoin to Dollar)

But I don't have anywhere to keep this money.
Have anyone already done this in any currency?
Would you describe how you've done it?

With no bank account: You can buy Bitcoin in your home country then sell them for cash in person in the US through sites like Local Bitcoins once you get to the states.
With large sums of money its good practice to wait for six blocks on the blockchain before considering the transaction confirmed.
With a bank account: Non-U.S. citizens are allowed to open a bank account in the United States. You can wait to open a bank account in person when you arrive or try opening a bank account in your home country at a bank that operates in both your home county and the US. (In Brazil HSBC is one example of a bank that operates in both counties).
To sell your Bitcoins get an account at an exchange like Coinbase or Circle, trade your Bitcoins for USD there and connect that with your US functional bank account to withdraw the funds.

Thank you for your reply, I would try to open an acc here in brazil, but HSBC no longer operates here.


text:
Can I access a BCH wallet with a BTC seed phrase?
So I've accidentally given someone a BTC address and she sent BCH to this address. The wallet was created post-fork. Is it possible to go through the same process as accessing BCH immediately after the hard fork, or are these BCH funds lost forever?

Related: https://bitcoin.stackexchange.com/questions/57713/bitcoin-cash-accidentally-sent-to-bitcoin-address-can-i-get-them-back

If the seed phrase was generated by a BTC BIP-0039 compliant wallet and you have a BIP-0039 compliant BCH wallet then the answer is yes you should be able to get hold of your BCH funds.
It should be easy to try. Get a BCH wallet and enter your seed phrase and see if your coins appear.


text:
How does bitcoin handle unspent outputs from fresh transactions?
I read that Satoshidice uses one of the outputs from the bet transaction to fund the response transaction.

Can anyone provide explanation/reference to how bitcoin handles such transactions.
What is the rationale of allowing such transactions?
If the protocol did not allow unconfirmed unspent outputs to be used, would that make bitcoin unusable?

Bitcoin protocol doesn't care how many confirmations a transaction has. A user can choose any number of blocks that has to be mined on top of the transaction before considering it confirmed, or in case of Satoshidice it simply doesn't care.
Bitcoin protocol does care that source addresses of a transaction has all required coins to transfer to destination addresses, in other words a transaction has to have all it's inputs to be valid and the number of coins those inputs have must be greater or equal to number of coins in outputs. Therefore if an attacker successfully double spends his transaction to Satoshidice it will also invalidate winning transaction from Sathoshidice, because one of the inputs of winning transaction is the original transaction from the attacker to Sathoshidice.
To answer the question why bitcoin protocol allows it, consider two transactions

From address A to address B
From address B to address C

To think about second transaction as confirmed you need to wait a certain number of block to be mined on top of it and it doesn't matter how many block were mined on top of the first transaction because it doesn't make second transaction any more secure. Therefore both transactions can appear in the same block and that's completely fine.


text:
Why is there an output with op-return in regtest mode?
Here is an output from getrawtransaction:
{
  "txid": "a2b9e3aa4adeb68a9b8b8b0bbc8d4890585cd711e89cda83e7f236397fac6218",
  "hash": "6d96c04d49eefe3eab4934188841ef3592c818bf789517b90b1f71ff75a14c26",
  "version": 2,
  "size": 183,
  "vsize": 156,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "02b0010101",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 12.50000000,
      "n": 0,
      "scriptPubKey": {
    "asm": "03d81b3d2ac76e322dcb2e713cb8fdeaf68cb83406c0e4d28dcd10a880ef172a6a OP_CHECKSIG",
    "hex": "2103d81b3d2ac76e322dcb2e713cb8fdeaf68cb83406c0e4d28dcd10a880ef172a6aac",
    "reqSigs": 1,
    "type": "pubkey",
    "addresses": [
      "mwzWcEU4kBkJPSTgB8LSBfvyaEjdXmyGh7"
    ]
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
    "asm": "OP_RETURN aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
    "hex": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
    "type": "nulldata"
      }
    }
  ],
  "hex": "020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0502b0010101ffffffff02807c814a00000000232103d81b3d2ac76e322dcb2e713cb8fdeaf68cb83406c0e4d28dcd10a880ef172a6aac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000",
  "blockhash": "4742b345fb92ce66f5fccaa880ebef29ebe44d8649114ddb06c4f7177047a717",
  "confirmations": 1,
  "time": 1512718207,
  "blocktime": 1512718207
}

I am interested in this bit:
{
  "value": 0.00000000,
  "n": 1,
  "scriptPubKey": {
    "asm": "OP_RETURN aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
    "hex": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9",
    "type": "nulldata"
  }
}

Who created it? (I am using regtest mode)

You did, presumably.
The transaction you're showing is the coinbase; it's a  special transaction added by the miner. The OP_RETURN output is the SegWit block commitment. It is the Merkle root of all transactions' wtxid (a txid that includes the witnesses), thereby making sure that the block commits to all witnesses.
When running in regtest mode, you probably directly or indirectly from a script called the generate RPC call, which produces a new block. If there were any SegWit transactions in the block, the commitment is mandatory (and optional otherwise).

If I'm following you answer correctly, I don't have any SegWit outputs in my regtest block. The block has only the coinbase tx. And this tx's single output is to a legacy m address (thus not SegWit). Still I get an OP_RETURN and its data is not a utf8 string.

The segwit commitment is always created, even when there are no segwit transactions. It is not mandatory (a block without witnesses is permitted not to have such a commitment), but Bitcoin Core will always create it. It's not expected to be human readable or a string; it contains a hash of the wtxid merkle root.


text:
Does bitcoind send message headers and payload separately in P2P protocol?
I am connecting to my local bitcoind using TCP and observed the following behavior:
I see many messages where only header is given or only part of the payload is attached. Of course, it could be a bug my code too.
Are the bytes sent in chunks? Which of the following are valid?
|header1|payload1|     (as per documentation, this is valid)
|header1|              (no payload, even though required. Have seen this)
|payload1|             (no header, have seen this)
|header1|partPayload1| (incomplete payload, not sure if seen these)
|partPayload1|         (part earlier header's payload, not sure if seen these)
|header1|payload1|header2|payload2|
|header1|payload1|header2|partPayload2|
|header1|partPayload1|header2|
|partPayload1|header2|payload2|

Note: I am using version number 70002, relay = 1 and services = 0.
EDIT: Generally I wait for the remaining bytes, and most of the times they arrive, but in rare cases, around 2%, some other header arrives. This happens only with tx messages.
EDIT2: Based on the comments below, it seems likely that there is a bug in my code. I'll check and revert.
EDIT3: Was a bug in my code. I was assuming that partial data packets correspond to a single header. There can be multiple headers after the data is complete (in the same packet). This makes sense once I consider it as a stream.

TCP is a stream protocol. Even though on the wire the stream is submitted as a series of IP messages, semantically it is just a stream of bytes.
This means that at the application level you shouldn't care about the message boundaries. Routers and other internet infrastructure can arbitrarily split up data into packets to fit in their underlying protocols (e.g. Ethernet has frames of at most 1500 bytes).

I am reading the data from socket and it comes incomplete (the first three cases, I have observed when connecting using TCP).

What do you mean by incomplete? It's just a stream of bytes. If a read from the socket returns and you don't have a full Bitcoin P2P message yet, it means the rest will come later.

The header checksum verifies, says payload should be x (non zero) bytes but the message is either only 24 bytes or less than 24+x. So I need to wait for the rest of the message, with the guarantee that the peer has actually send the complete data and its on the way, and it won't send header of a different message. Right?

Then that means you haven't seen the entire message yet. You'll see the rest in a subsequent socket read.

Edited my question to explain the symptoms instead of extending the comments.

What do you mean by "another header arrives"? If the previous message isn't complete yet, then the first bytes that follow belong to that message.

The next message instead has the magic bytes, while the earlier payload was not fully received. Is it possible that the packet was lost?

That sounds wrong. Bitcoind should not do that (there can be a bug of course, but that seems unlikely as it would be very noticable).

Does bitcoind send messages as follows? |header1|payload1|header2|payload2| or is it always only one message at a time?

Why does it matter? TCP is a stream of bytes. You can't tell in which way those bytes were broken up in syscalls by the sender, and you shouldn't care.


text:
If SHA256 and/or RIPEMD-160 were broken, would all bitcoin addresses be compromised?
If not, what else would be needed to steal all funds from all people and completely break bitcoin?
I bet some will say ECSDA gives bitcoin an additional layer of protection. I counter this by saying ECSDA is dependent on a hash function such as SHA256. So I will ask this as well: What kind of ECSDA does bitcoin use and would it still be protected if SHA256 were broken?
Yes, I know I am illustrating an unlikely scenario but I still believe we should know what will happen.
If you want to mention other hash functions in relation to SHA256, you can. Feel free to explain how RIPEMD-160 would keep bitcoin safe in case of a SHA256 exploit.

Bitcoin uses SHA256 followed by RIPEMD-160, which I'll collectively call HASH160.
Good hashes have 4 properties:

it is easy to compute the hash value for any given message
it is infeasible to generate a message that has a given hash
it is infeasible to modify a message without changing the hash
it is infeasible to find two different messages with the same hash

Source: Wikipedia
We care about properties 1, 2, and 3. We know for a fact that property 1 is true about HASH160 - we can benchmark it. If properties 2 or 3 were false, then you could steal bitcoins. Not good.
It's a good thing that the scripting language is so flexible, and would allow people to switch to a different address type without forcing everyone to upgrade.
This is a current bitcoin transaction script:
 OP_DUP OP_HASH160 09432ab39083b5098b6f09432ab39083b5098b6f OP_EQUALVERIFY OP_CHECKSIG

Here's how that might change if HASH160 were broken:
OP_DUP OP_HASH256 09432ab39083b5098b6f09432ab39083b5098b6f09432ab39083b5098b6f826496 OP_EQUALVERIFY OP_CHECKSIG

Note that we've swapped HASH160 for HASH256. Or, assuming both were broken:
<pubKey> OP_CHECKSIG

Now we're forgoing hash functions entirely and putting in the ECDSA key explicitly. However, this would make bitcoin addresses about a hundred characters long.

Could you elaborate on what would be necessary to "switch to a different address type" insofar as what users with bitcoins on the old address type would have to do to move over. Would everyone just have to create new addresses and move all their bitcoins?

@BT Yes. The addresses would be much longer, though.

Got it, cool. That doesn't sound so bad actually then. At least, not catastrophic.

To spend bitcoins, you need to have the corresponding private key. The bitcoin address is derived from the public key. If the hash function could be compromised regarding 2. one could reveal the public key. This would still require elliptic curve cryptography to fall apart before an attacker could steal your money. An attack to 3. does not help for a bitcoin address at all. Finally if 4. would be weakened it would still not really help as you would have to randomly generate key-pairs to find a collision. You can already do that now but chances are bigger to find alien life in universe.

Nick's answer is very helpful, but might not be sufficient to get us (and BitCoin) in the clear. There may be a valid and grave concern based on the fact that crypto hashing functions aren't proven to satisfy constraints 2 and 3, so they potentially can be weak.
Even though people could switch away from a crypto hashing function to a better one, what would allow us to know for sure that someone isn't silently using the weakness of the hashing function to steal? Going undetected would allow you to leech from the bitcoin system, perhaps by getting a enormous share of mining rewards without expending nearly as much computing power. This kind of arbitrage could allow you to get rich off of every nerd who uses BitCoin (admittedly myself included) and some venture capitalists (I'm getting there ;) ). And since we're speculating, wouldn't it be convenient to tie develop a currency based on crypto if you want to get really rich. Obviously, exploiting it without removing its potential for growth and adoption...
If you know the exploit to SHA-256 and know how to leech off BTC and other crypto currencies, the altruistic and honorable thing to do is publish the exploit. The egocentric thing to do would be to abuse it.
I hope that someone will prove me wrong about this potential for abuse.
If not, it basically comes down to this: with great power comes great responsibility! Everybody says trust isn't needed with BitCoin. It STILL comes down to trust, but now trust that no one came up with this loophole or that the one who did isn't breaking the system more than it's contributing societal value.
I'd really have big respect for the person for choosing honor above personal gain. Unless you siphon the gains to a good cause, but even then I'm sure that a single person isn't best capable of handling those amounts of value. A crowd or even a market knows better how to allocate funds somewhat optimally.

If you knew an exploit to a major crypo algorithms like SHA256, you could sniff people's passwords through SSL, crack their back accounts and drain them of fiat in a swift weekend.    I think bitcoin would be the least of the worlds concerns.


text:
How can I buy Bitcoins in the UK now that Blockchain.info has suspended its deposits?
After blockchain.info suspended Pingit, there is no convenient way to buy a small quantity of bitcoins. Any other alternatives to acquire bitcoins (mining or working are out of the questions.)
I've heard a SEPA transfer will allow UK bank accounts holders to utilize European exchanges, unfortunately I am concerned about the legality of these exchanges (ie: who owns/runs the exchange, for example.) As such I would like the company to be based in the UK, where I have more protection if the transaction goes awry.

possible duplicate of How do you obtain bitcoins?

doesn't mt gox allow bank transfers or cc payments?

For small BTC purchases in the UK, https://localbitcoins.com/ (LocalBitcoins) is the only viable option right now that I know of.
There are other methods, mostly involving bank transfer arrangements, but be very careful to figure out how much you end up paying in total fees for it. It doesn't make much of a difference with large BTC orders, but for small amounts it's a fair % of costs.

SEPA purchases are callbackable up to 10 days, so if you trade over SEPA transfers make use you pick LocalBitcoins.com user with high reputation http://localbitcoins.blogspot.fi/2013/06/localbitcoinscom-bank-account-frozen.html

QuickBitcoin (http://quickbitcoin.co.uk) accepts UK bank transfers for bitcoins.  There are no fees, and transactions are very quick.

that looks well dubious and a rip off

No fees but the exchange rate is pretty bad (approximately 5% higher than current market price at the time of writing).

I prefer to use the Bitcoin comparison tool found at: http://cheapbitcoins.co.uk - you can get the best prices for in GBP, because most bitcoin exchanges are not based in the UK.

I have tried using BitBargain.co.uk - it is a cut above the Mt Gox price, but not as much so as QuickBitcoin. You'll likely get a better deal if you can find someone on LocalBitcoins though.


text:
When does MtGox lock accounts?
When you sign up at MtGox, they say: please fill out the following to avoid your account getting locked.  They're referring to the member verification process (using govt ID and utility bill).
But under what circumstances will they lock my account if I cannot provide verification docs at the moment?  And what does "locked" prevent me from doing?  Does it prevent me from, for example, transferring BTC to another exchange or wallet?

This question appears to be off-topic because it is about a provider that is no longer in business.

I recently got mine locked because my YubiKey broke.
When you want to disable the YubiKey for your account, your account will be frozen for two weeks. I had my account information verified and still got locked.

What you call "locked" is more exactly "AML flag", concerning money laundering regulations.
More or less everything that is "suspicious" can get you AML flagged.
A few publicly well known examples that will get you flagged are if you are accessing mtgox from the TOR network or other anonymous proxies; also if you are accessing many mtgox accounts from the same IP address.
 Many other reasons could get you flagged, most of them are not publicly known.
Being AML flagged will lock any withdrawal attempt, even for BTC withdrawals.
You will still be able to deposit and trade, but you wont be able to withdraw, until you verify your account with ID doc and utility bill.

Citation needed.

feel free to cite myself or magicaltux from the official mtgox irc channel ;) see also https://support.mtgox.com/entries/21651045-AML-Account-Statuses

That page makes no mention of "locked" accounts.

there are no "locked" accounts, there are limited accounts because they have been AML flagged for any suspicious activity and will need to verify to remove the withdrawal limits, that is respecting AML laws : http://en.wikipedia.org/wiki/Money_Laundering_Control_Act http://en.wikipedia.org/wiki/Anti_Money_Laundering


text:
Is it safe to store all my coins on Coinbase?
Is it safe to store my coins (BTC & ETH) on the Coinbase platform or is it safer to download a wallet to keep them in?

you should download a wallet to keep your coins. While your coins are sitting in an exchange, they do not necessarily belong to you.

Sorry this is a personal question that cannot be answered. It depends on your comfort with risk and technical confidence. Coinbase can be hacked, or the government could seize your funds (Greece, Cyprus, India). Compare that to you could get hacked, or lose your password.

Also as a side note dealing directly with the btc had trade offs too. There are many cases of lost  wallet public keys and or private keys, sending to a public address for which the private key is not known etc. Even a typo or wrong digit amounts to the destruction off btc ownership. Bitcoin works well but may be unintuitive for even the smartest person. What ever you do exercise caution and be certain when handling btc directly.

I would recommend diversifying your btc holdings as much as possible. What if something happens to your wallet? That wouldn't necessary be better than coinbase. You could keep some in a personal wallet, some on several exchanges. Ideally by diversifying your capital, you can some what mitigate commonality of the risk. This prevents the possibility of a single devastating loss.
That said consider some alternative, if there is a single fault, but the probability is very low, that may be a good choice.
Consider https, which typically relies on one main root of trust who's security has been well verified, compared to some of googles authyoath crap (which places trust on a diverse sequence of relatively completely insecure mechanism) which have been hacked whilst https remains secure.
P.s. Google, stick to search engines.

That being said, advice is often easier given than taken, my btc reside primarily on gdax o.o

Coinbase allows the purchase, sale and holding of three cryptocurrencies as of 7/4/17. Bitcoin (BTC), Ethereum (ETH) and Litecoin (LTC) are supported on the Coinbase platform and there is also a U.S. Dollar wallet (USD) where you can store U.S. Dollars from sales of coins or from transfers. Coinbase has insurance that protects every customer against the loss of digital currencies. If digital currencies are stolen, Coinbase's insurance company will make you whole. Also, if you are a U.S. Citizen, your U.S. Dollar wallet (USD) is protected up to $250,000.00 by F.D.I.C insurance. The USD is where you park your cash before a purchase or after a sale. I store 99% of my digital currencies on Coinbase and I sleep quite well.

While your coins are safe enough for you to sleep happy, you should remember that Coinbase can close/freeze your account, for example the Free Ross account was suspended (later reversed).  They can and do also close accounts for other reasons, for example sending your bitcoin directly to/from known gambling sites as outlined in their TOS "You may not use your Coinbase Account to engage in the following categories of activity... Gambling".

Thank you for your answer, am trying to figure where to keep my coins, and knowing coinbase is insured like this makes me feel a lot better than a software wallet which could be emptied one morning some hacker finds my keys, with zero recourse but crying.

But read the fine print "Please note that the insurance policy covers any losses resulting from a breach of Coinbase’s physical security, cyber security, or by employee theft. This insurance policy does not cover any losses resulting from the compromise of your individual Coinbase account. It is your responsibility to use a strong password and maintain control of all login credentials you use to access Coinbase""  from https://support.coinbase.com/customer/portal/articles/1662379-how-is-coinbase-insured-

I wouldn't do it.
In case you do that you trust all your Bitcoins to someone who may be hacked or go out of business.
I would keep my coins in cold storage.

Thanks for the response. So which wallet do you recommend? (BitcoinWallet?)

Also are these wallets currency specific? Meaning ... if I download BitcoinWallet, can I put Ethereum in there too? Thank you.

I use bitcoin-qt but there are many out there you can use. With bitcoin-qt you don't relay on anyone, you're part of the network and your wallet is kept by you. Regarding your second question, it may depend on where your wallet is, if it is kept on an online provider you may be able to have diferent wallets keep by him, but I don't know about this.