text:
ECDSA x,y coordinate validity verification doesn't seem to work
The ECDSA algorithm, secp256k1 for Bitcoin allegedly uses the equation
y ^ 2 = x ^ 3 + 7 mod P
to determine the validity of an alleged point upon the elliptical curve.  Utilizing
http://web2.0calc.com/
When verifying public key 1 which has the following qualities:
x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
I applied x ^ 3, then added 7, then mod P on that webpage.  Then I square rooted it and got
180964706334543048141953325634608696715.426683454595872
Which is not y.  How am I doing this wrong?  My results suggests that this point is not a valid point on the curve, but everyone knows it is.  Obviously I'm the one who's wrong.
EDIT:  I'd like to further clarify the question.  My question is, how does one actually determine (as an example) the Y value while only having the X value.  Bitcoin does it, the "Bitcoin Address Utility" also does it.  When someone has a compressed key (which only contains the x coordinate) they are able to get the y coordinate as well.  Utilizing the aforementioned webpage calculator does not work and others are saying its "modular root".  Anyone have Python 2.7.7 code which would do this or have a relatively simple way of explaining how to accomplish this whole thing?  Thanks.

PyBitcoinTools uses these lines.  As Pieter said, it's quite complicated.

Related: https://security.stackexchange.com/questions/233099/validating-an-ed25519-public-key

The plain text format of this equation only makes sense when you understand the theory behind it.  y ^ 2 = x ^ 3 + 7 mod P means "do all math in this equation using the finite number field with definition P".  It might better be written (y^2 = x^3 +7) mod p.
To keep the math simple, lets simply subtract one side from the other to see if that evaluates to zero.  This lets us avoid roots. Here's code using the Python interactive shell, e.g. python from a command prompt):
>>> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
>>> y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
>>> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
>>> (x**3 + 7 - y**2) % p
0

My goal is to be able to determine y, when all I have is x.  I do not disagree with your conclusion that it is ideal to avoid square roots.

Was this ever solved?

From your X value, you can get 2 possible Y values.
y^2 == (Y * Y) == (-Y * -Y)    (mod p)

Depending on the format of the public key in the bitcoin transaction input,
you can figure out which Y is the one you want to validate against.
If the public key starts with 04, then Y is already present in the public key and you don't need to do any calculations to find Y
If the public key starts with 02, then the Y value you want is an even number.
If the public key starts with 03, then the Y value you want is on odd number.
Using your example for X,
X = 55066263022277343669578718895168534326250603453777594175500187360389116729240

I compute the possible Y values are,
Y1 = 32670510020758816978083085130507043184471273380659243275938904335757337482424
Y2 = 83121579216557378445487899878180864668798711284981320763518679672151497189239

Choose your Y depending on the format of the public key in the bitcoin transaction input.
Python code,
p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
ysquared = ((x*x*x+7) % p)
print "ysquared= %s " % ysquared
y = pow(ysquared, (p+1)/4, p)
print "y1 = %s " % y
print "y2 = %s " % (y * -1 % p)

I prefer to look at my numbers in hex format, so here is the same example output as hex.
X = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Y1 = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Y2 = 0xb7c52588d95c3b9aa25b0403f1eef75702e84bb7597aabe663b82f6f04ef2777

Python code,
p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
x = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
ysquared = ((x*x*x+7) % p)
print "ysquared= %s " % hex(ysquared)
y = pow(ysquared, (p+1)/4, p)
print "y1 = %s " % hex(y)
print "y2 = %s " % hex(y * -1 % p)

An example transaction containing the public key X,Y1 (0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)
https://2xoin.com/tx/8e2c570498680261040ceffdd15e67dda6c00a885d1e5484f220125f3a5e2c56
At the time of writing, there were no transactions using the public key X,Y2

To go further on David's answer, the hardest part is actually the square root. It's just the number that after squaring modulo P ends up being the result you had before. That's a modular square root, and you won't easily compute it using regular arithmetic (unlike modular additions, multiplications or powers).
This wikipedia article section has more information: http://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus

How is bitcoin determining the y coordinate when it has only the X as in compressed public keys?

We ask OpenSSL (for now), which uses computes the (p+1)/4'th power of the number modulo p, as is listed in that Wikipedia article above.

You can also decode from b64 Q29udGFjdCBtZSBhdCBhZGl0ZWMzNUBnbWFpbC5jb20=
the:
x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
I applied x ^ 3, then added 7, then mod P on that webpage. Then I square rooted it and got
180964706334543048141953325634608696715.426683454595872

authors: عزالدين بدارين


text:
Given a private key, how do you get a public address

Possible Duplicate:
How are public & private keys in an address created?

I am scanning in a private key from a QR code in an app I am writting to handle the import of physical bitcoins.
Given a private key, how can I get the public key so that I can lookup its value on the block explorer?

Do you want the algorithms? Do you want code in a specific language?

Yep, that question answered it.

@RobKohr I made a practical example here: http://bitcoin.stackexchange.com/a/29811/1761 I hope this help you.

In ECDSA public keys are usually generated from a random private key. The simple answer then would be, that instead of using a random private key, you use the given private key and it should generate the public key. After that, perform the steps listed in the Wiki to find out the conventional notation for the public key you can use anywhere.

source: Stack Exchange

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

sort: votes


text:
Where can I register a .RU domain and pay with bitcoins?
Where can I register a .RU domain and pay with bitcoins?
(There are several services offering the registration of "international" domains and accepting bitcoin payments, but what about .RU domain?)

Your recent posts seem to some people like spam / rep-whoring. http://meta.bitcoin.stackexchange.com/questions/253/what-is-the-limit-of-self-answering

@ripper: No, this is a specific question, and it costed me substantial effort to find the anser to this specific question: most of the known services do not offer .RU registration. So I had to check them one by one, find for each one the list of domains that are available, and look for .RU there. By posting this question and answer, I save the time and work of other people with the same need as mine.

You can edit the answer to the other generic question to pinpoint the RU domains ... essentially the two questions are so alike, they should just be one question.

@ripper234: no, this won't be a usable solution, because it would just dump the huge amount of information into the answer which a person looking just for .RU domain registration will have to look through, and this won't save the effort for him/her.

There is a list of domain registration services at https://en.bitcoin.it/wiki/Trade#Domain_Name_and_DNS_Hosting. Among them, I could find .RU registration only at:

http://www.cinfu.com/domains/ ($9.17/year)
https://www.kalyhost.com/domain.html (for 18 EURO a year = 4.45BTC)
???

Frank Domains has entirely integrated its payment system with Bitcoins. They sell all TLD's and also a substantial number of ccTLD's, including .ru (http://www.frankdomains.com/.ru).
Its also relatively cheap for only 1.49BTC
There are other alternatives, but I prefer Frank Domains due to their extra security options.

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


text:
Does the bitcoin block contain minimal transaction detail? (Is it as private as possible given the proof-of-work design?)
From https://crypto.stackexchange.com/questions/508/could-one-prevent-double-spending-in-decentralized-digital-currencies-like-bitc
"Now, the only information about the transaction that needs to be public is enough information to prove I have the coins and prove that I didn't transfer them elsewhere. As it happens, the Bitcoin protocol leaks much more information than this (for example, the account I transferred the coins to). The protocol could have been designed to make less information public if that was desired."
Is this true, could the block-chain report less data but still gain the proof-of-work mechanism's benefits?  If so, what aspects of the blockchain are non-essential and what is the reason for including them?

Great question, +1 and welcome!

Thanks!  I'm really interested in this, since anonymity (pseudonymity) is such a feature of bitcoin, I can't imagine why the protocol wouldn't minimize the transaction information if possible.  I'm very curious who made that decision and why, and what the repercussions are for broader adoption of BTC.

In order to send someone some coins, you need to know their public address.
In order for them to redeem their coins, they have to show everyone that they possess the private address associated with that public address.

You could try encrypting your public key by some means and later decrypt it when you want to spend the coins, but you'd probably have to provide something that could identify you similarly to using a public key.
You could alternatively encode only transaction hashes in the block, rather than actual transactions and only send the actual transaction to the peer you are sending the coins to. This approach though creates a lot of new problems with validation and so forth.
All in all, Bitcoin protocol doesn't have much excess data. In fact, by today's standards one may say it is trying to be too slick at times (say by using something like VarInt).

To be able to prove that you have the coins, it is necessary to be able to prove where the coins are (ie, what address they're at) right now. This means the public ledger has to show the movements of the coins. Otherwise, how do we know the coins are in your wallet and not another wallet?

Users may choose (perhaps unintentionally) to add identifying information, typically through re-using addresses. If you use a different address for each transaction, you are more anonymous than if you use the same address (thus creating a link between all your transactions, so any information leak associated with any one of them might serve to de-anonymize them all).

I'm not a crypto expert but I think the answer is exactly the opposite, Satoshi chose to give out less information than he could have.
To use PGP encryption you publish a public key that anyone can use to send a message that only you can read. Typically your public key is available to everyone in the world, including the NSA, from a public keyserver. This is convenient, someone dosn't have to email you and say "Hey guy, I need your public key to send you a private email".
The NSA might have spent the last 17 years cracking my old 384bit public key to read a couple of email replies I got in 1994 saying "Re: can I sleep on your floor after the 2600 meet? Yeah dude bring a sleeping bag".
A bitcoin address is a hash of a hash of an ECSDA public key. That is just as identifying as the public key, or a non-existent "account number" since it is unique to the person receiving the money.
There is loads of money sitting in the bitcoin block chain. To take the money from an address you just have to provide a number that meets certain conditions. The whole thing rests on it being really really difficult to find a number that meets the conditions if you don't have the private key that was produced along with the bitcoin address.
Satoshi could have just had the bitcoin software publish the public key. That would mean that if someone dosn't spend some bitcons for 15 years an attacker has 15 years to try to crack the ECSDA crypto. That should have an insignificantly tiny chance of success but there is no harm in making it more difficult.
In theory the hashing means that there are more possible numbers which satisfy the condition to get the money. That should reduce the cracking time from a 1000 zillion years to only a zillion years, which dosn't matter. In practice it means an attacker has to crack ECSDA plus two hashing algoristhm instead of just ECSDA so it's probably more difficult in practice.

I agree that the system is quite private.  What I'm not sure is whether it's as private as possible, and if not, why not.  Specifically, does the blockchain include more information than necessary, information that makes it easier to track people's activity if their public address becomes known.

"I'm not a crypto expert but I think the answer is exactly the opposite, Satoshi chose to give out less information than he could have."
That is not the opposite and not the focus of the question.
Every protocol that I can think of that is used today gives less information than it could.


text:
Trojan Clients?
The Bitcoin client is downloaded from a non-HTTPS server, so you cannot verify that it is legit, and the installer exe is not digitally signed. How often does that result in a Trojan client, and why is it done in this way?
I understand that you should check the pgp signature of the file, but if you do not have https, then how do you know the pgp signature is not just as bogus as the file itself? Don't we need https too?

See How can one download the Bitcoin client securely?

github also doesn't support https downloads. though the download 'area' is https, the actual files are pulled from http://cloud.github.com
you really are barking up the wrong tree with the https bit, since all https is telling you is that the server you're talking with is who it claims it is. if server is compromised, it will serve you a trojaned file just as happily as any other file.
what you really want to do is verify the pgp signature of the file (or of a file containing a hash of the released file), made by the developer making the release. you can do this regardless of where you download the files - both github and sourceforge contain the gpg-signed sha1sums file that you can verify the signature of to ensure file integrity and authenticity. the only way that could be compromised if the developer's machine itself was compromised.

As to why, here's a recent comment from Gavin Andresen:

I'd like to switch from sourceforge to github for binary release
  downloads, because sourceforge doesn't support https for downloads.

So, most likely we'll have HTTPS downloads soon.

see my answer below. github downloads are not https either - and the whole https bit is beside the point, anyway (imo).


text:
OS X 10.7 - Where is Bitcoin data stored?

Possible Duplicate:
Is there wallet.dat for OSX?

Upgrading my HD; clean install and I want to copy the wallett etc from old hard drive. What do I need to copy? Thanks in advance.

Bitcoin data on Mac OS X located in ~/Library/Application Support/Bitcoin/ . Just copy the whole folder to the new HDD to use your old wallet and downloaded blockchain with the new copy of Bitcoin client.


text:
How to preserve anonymity within Ripple?
The common practice for cryptocoins like Bitcoin is to limit address reuse to preserve anonymity. This is achieved by sending the "change" of a transaction to another address and using a unused address for every transaction. (Research showed that even when best practices are used identities could be derived but that's not the point here).
The Ripple wiki documents something about an Account Familiy which seems comparable with Bitcoins deterministic wallets as decribed in BIP0032. However the Ripple system requires a fee for account-activation.
When using an account family how does one activate such account and how does (I presume) rippled know that an account from a family is activated?

Note, anonymity isn't a design goal for ripple. Depending on the level of pseudo-anonymity required, gateway and future features of Ripple would likely be easier (and more cost effective) than using many Ripple addresses (aka Ripple accounts).
To tell if two (or more) Ripple addresses are in the same family you need the public generator (which is named for generating the public keys, it should not be made public). Without that no one can tell if they are part of the same family and therefore they are funded/activated independently exactly like any other address is (someone sends it the XRP account reserve).
I'm not aware of any Ripple client that currently implements account families (the existing clients just use the public and private ECDSA key corresponding to index 0 within the account family).

I'm a bit surprised to see that Ripple doesn't aim for anonymity. I don't really agree with the points on the Ripple Wiki about providing adequate anonymity:
If you ask your friend to pay you a certain amount (and he doesn't use a proxy) you know his address and you can easy inspect the network to see if he has made payments to a explicit party. Bitcoin doesn't have this problem.


text:
ECKey.ECDSASignature creation
I have my ECKey key. In order to create an ECDSASignature object with BitcoinJ, we have to call ECDSASignature mySignature = key.sign(Sha256Hash input).
Is the Sha256Hash input my message? Or is it the result of Sha256(byte[] myArray)?
What if I don't have a message to sign? Is it acceptable to sign the key.getPrivKeyBytes() in order to create an ECDSASignature, or it is unacceptable because it reveals information including in getPrivKeyBytes() and as a result reveal my private key?
And if it is unacceptable what must be my message? Can I can sign whatever I want in order to create my ECDSASignature?

Are you trying to sign a transaction? There are better ways of doing that in bitcoinj. What are you trying to sign?

Let's say that first: i am trying to sign a transaction and as a second secnario that i am going to sign a message in the form of String variable.Which are these better ways?Thanks.

http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

Thanks. I will actually create a message (as a String variable) rather than a whole transaction,and finally i will sign this message to fulfill my program's functionality desires.

@Top If you're trying to sign a transaction, you should use Wallet.signTransaction(Wallet.SendRequest.forTx(transaction)); If you're trying to sign a message, you should hash the message first with SHA256.

Signing the bytes of the private key of ECKey key is unacceptable because you are vulnerable for realeasing information about your private key.
In the case of signing a message(as a String) you have to estimate the :
 byte[] result= sha256(message)

The result will be a byte[] and this array finally will insert to the :
 Sha256Hash input= new Sha256Hash(result);

Then the procedure is simple in order to produce the ECDSASignature.
You have to do the following:
ECDSASignature signature= key.sign(input);

and finally in order to validate your signature you have to check the following:
key.verify(input, signature)


text:
Electric power efficiency - why is increases so fast
How were the Antminer hardware made to decrease electric power consumption by half with each new product, like at the current generation of S9?
What are the projections to future efficiency that can make current hardware obsolete?
Why can't Intel do the same with their Core i7, and why do smartphones not last much longer on a battery charge than several years ago?

The main reason that miners can gain power efficiency at a faster rate than smartphones is because they lack the hardware the consumes the most power:  the screen.
Intel is constantly making more energy efficient chips, but when that only accounts for a small fraction of the power consumed by the phone, it doesn't result in impressive increases in battery life.
On the other hand, miners are practically nothing more than custom chips.  So when they increase the efficiency of those chips, the whole device sees a huge increase in efficiency.

This is true for mobiles and other devices with screen. I believe the question was more general though. Intel is making more efficient chips but in accordance to Moore's law. Until now, mining  hardware manufacturers were way behind thus allowing them to decrease consumption and increase processing way more than ×2 every 2 years (which is Moore's law).

Yes, that's definitely true, and was covered well by your answer.  I just wanted to make sure that anyone comparing power consumption between asic miners and mobile phones recognizes the obvious differences in what uses the power.

The mining hardware industry started very recently and their chip fabrication technology was way behind that of traditional chip manufacturers (ie Intel, AMD).
Chip energy efficiency depends on the distance between the transistors of a chip. The closer the transistors are the better. Intel produced their first 14nm (distance between transistors) in 2014. Mining hardware manufacturers resently produced their 16nm ones. They started with 28nm (or worse) ~4years ago.
Still mining hardware almost reached the chip density of Intel which is remarkable for only 4 years of development. It would be very interesting to see, if mining incentives remain high, whether it reaches or surpasses the big players in chip manufacturing.
Note that mining hardware is now very close to the best available chip so we can expect that the energy efficiency of mining would follow Moore's Law from now on (just as Intel hardware does).

There is another perspective: the world's joint experience in building chips has been focused on producing hardware with extremely low failure rate. Hardware that is twice as efficient, but produces nonsensical results 40% of the time is a perfectly good deal. This is a very different problem than the one Intel's chips are solving, and there is a lot to be learned about it.

This is indeed true. However, the massive decrease in consumption has to do with transistor density. Mining hardware will not have such improvements anymore; only those allowed by Moore's law similar to the big manufacturers.

I think that if you look at antminers specs you can see that they were very energy inefficient at the beginning. Their great rate of improvement thus stems from their terrible base (start) level.
Smartphones are in reality way more efficient than antminers on the whole... and it is harder for smartphone makers to improve at that stage than for Antminer.


text:
Testnet transaction - OPCODE MISSING OR NOT UNDERSTOOD error
I'm trying to broadcast a manually generated raw testnet transaction. I'm getting the following error from SmartBit: PUSH TRANSACTION ERROR: 16: MANDATORY-SCRIPT-VERIFY-FLAG-FAILED (OPCODE MISSING OR NOT UNDERSTOOD).
My raw transaction looks like this:
01000000
01
e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547
00000000
8d
493046022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
ffffffff
02
75a58c0600000000
1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac
23ce010000000000
1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac
00000000

Assuming that the error indicates a problem with the scriptsig, breaking down the scriptSig, it looks like this:
49
30
46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201
41
04
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

What am I doing wrong? The spender's address is: mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm.
EDIT:
I dropped the extra 0x04 and adjusted the 1 byte public key length. I'm still getting the same error. ScriptSig looks like this now:
49
304502202c5a951bbfc185ffbe6c8b74f587a4c4b1afbf99ad2c95050c938dbecdf6bc4b022100a3594fa9168bc8030a73f8fa9d277fad1765ec06d71e378e8637df1e367d260f01
41
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

quickly verifying:
410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
41 hex equals 65. So the following string should be 65 bytes, but it is 66 bytes. As arubi lined out, there is an error with the double "04" - it only needs one.
Quick proof: when I verify the pubkey, I get the right address:
    04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba
SHA-256 hash of PUBKEY
EF14CA0F83CCDA08F81806AEFADF80BA58CCCD12B149E028EF86F7B00C04C293

RIPEMD-160 Hash
13AA97D12703B051D9B670097BBF07E2CD78DE60

Adding network bytes
6F13AA97D12703B051D9B670097BBF07E2CD78DE60

SHA-256
AD3575F9D5422C0BD5AE472DA035E54601085FA5F018F4F72EF2ED5E96602B0C

another SHA-256
02D633422E210032443A4F5595C443C311CD64A5C762A7E354CCB6E510F1196B

First four bytes
02D63342

Adding 4 Bytes at the end of the network bytes line
6F13AA97D12703B051D9B670097BBF07E2CD78DE6002D63342

Base58 encoding
mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm

so the pub key is wrongly assembled into the sigscipt.
On the S-value: I can see, that it was extended with a double "0", but the value still remains "high":
checking S-value is less than N/2, no...
    --> S is not smaller than N/2, need new S-Value (new_s = N - s)
    new S=4ECBED0519B3649CBEF69530CA8726C4065E1AA8D9128939F120419D62B6313F

when changing the S-Value, the length fields might need to be adapted...
Just for curiosity: what tool are you using to assemble the tx?

Hi, thank you for your response. I'm not using any library or tool, I manually assemble the tx (writing a code). I did make the changes you suggested (dropped the extra 0x04) and changed 0x41 to the length of the public key (I thought it's a permanent value). I updated the question with the recent result. However, I'm still getting the same error.

hmmm - can you post the unsigned raw tx (as string), that you are signing?

01000000 01 e0b0d06568754a5cb6c14fd46161cd5ff94d8bdc4d6871282627c8ee9adf09d6 00000000 19 38e4a66db3089a4fbb814ded136c923f3bebc12b ffffffff 02 75a58c0600000000 1976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac 23ce010000000000 1976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac 00000000 01000000

no, I don't think so :-) You original tx above startet like this: version=01000000, V_IN_count=01, TX_ID=e6dc926ae5ffd4f6b83376c7df... Now what you posted, is a completly different TX_ID: e0b0d06568754a5c...

Let's ignore the high-s value in the signature for now : 46022100dc6c14b905647fc0efde3d37079853bb1cedbcdf2cfdecac6665a3b8b8b2395d022100b13412fae64c9b6341096acf3578d93ab450c23dd6361701ceb21cef6d80100201
The pubic key push seems malformed.  Why the extra 0x04 after the 0x41 bytes push?
04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba is a valid public key, so I'm assuming it's the 0x04 that's out of place.
The pubkey's own 0x04 byte at the start indicates an uncompressed pubkey.

Worth to note that the signature is not valid for this transaction.  Getting the low-s and re-encoding would be easy but useless.

You're right I accidentally added another 0x04. However, even after removing it, I still get the same error.

You probably want to sign this :
0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a91413AA97D12703B051D9B670097BBF07E2CD78DE6088acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000

Actually, the UTXO on testnet is made to a pubkey with the hash160 of C888D0146F2542B9CB06CFC7E1446D3022A61206 .  I think you're using the wrong key somehow.
The actual transaction is
0100000001e6dc926ae5ffd4f6b83376c7df00136cd27284977714f3ab2295f0bb91e13547000000001976a914C888D0146F2542B9CB06CFC7E1446D3022A6120688acffffffff0275a58c06000000001976a91413aa97d12703b051d9b670097bbf07e2cd78de6088ac23ce0100000000001976a914a9974100aeee974a20cda9a2f545704a0ab54fdc88ac0000000001000000

What does that mean? Given my private key 51DD5DDE37A44786A80EE8BDFA0E6A7E953EDABC01AC9CB257D0AA7CC5A33A71, I received the following public key: 042d7331345e0da6ab1125eb39488a542a9923f31c585c20114d211a9f6bc9f3bf55d1d843cb7cf1d36b32d1cb00d2f140ef028e726a19a766f6ca7cef7b956583, but when I used a tool for signing the transaction, it gave the following (correct) public key: 040b4a4274222d7239d33c17ce39d753eee97103773b7e5a89e62f0ef0121032d7331345e0da6ab1125eb39488a542a9923f31c585c20114d211a9f6bc9f3b. How can I generate a valid public key on the testnet?

The pubkey for 51DD5DDE37A44786A80EE8BDFA0E6A7E953EDABC01AC9CB257D0AA7CC5A33A71 is 042D7331345E0DA6AB1125EB39488A542A9923F31C585C20114D211A9F6BC9F3BF55D1D843CB7CF1D36B32D1CB00D2F140EF028E726A19A766F6CA7CEF7B956583 .
The second pubkey looks invalid.  Too few bytes.
You should be generating pubkeys the same way for testnet as you would for mainnet.

It was an error by my part, the second (correct) pubkey is a compressed one: 03773b7e5a89e62f0ef0121032d7331345e0da6ab1125eb39488a542a9923f31c585c20114d211a9f6bc9f3b


text:
Is performance really important when choosing a language for a trading bot?
The C programming language outperforms interpreted languages such as Python or Ruby, but when it comes down to programming productivity, it is much easier/faster to write a Python program than a C program.
Considering that I want to write a trading bot, what would be the most appropriate language? If I use C, will I see a noticeable performance difference, or would the latency from HTTP calls make my decision time irrelevant?

This is just a general programming question.  It belongs on Stack Overflow, not here.

@Chris Acheson Maybe. But for example, MtGox has websockets which reduces latency a lot I think... I have no idea how other forex/stock exchanges work. If I went to stackoverflow I would have to write: "considering that I want to use the API from Bitcoin's exchanges...".

Then it's a question about websockets.  Still a programming question.

Specifically, the reason it's off-topic is that this question could apply to any type of trading bot, Bitcoin or not.

No. The trades in Bitcoins just aren't that frequent. That is relevant to HFT in stocks, where there are many thousands of trades per second.

Thanks. All that talk about "renting the closest apartment to Wall-Street because of 10ms" got me thinking a lot about performance.

that is because you are literally banking on those extra ms to be able to arbitrage extremely tiny opportunities. (Same as those platforms between the US and UK.) http://www.cityam.com/wealth-management/the-optimal-locations-hft-systems

The latency for gathering information and executing decisions will swamp the performance difference between languages. That assumes you don't write horribly awful code, but you can do that in any language. You should use whatever language you are most proficient in or whichever one you find easiest for the task.

If you want to base your work on the original client, you might find it easier to use C++, since that was the original client's sourcecode language.  However, the performance difference is negligible for different languages (especially when you take into account network latency as a speed-limiting factor), so you'll probably want to use the language you're most comfortable with for a trading bot.
Where you might want to consider performance a little more is if you're writing a program to mine Bitcoins.  In that instance, you may be able to get a C/C++ program (or even assembly) to perform a little better than an interpreted language.

Performance of the language isn't the most important factor in such a chunk of code. Room for error is the biggest I think. C if you are very good at writing C, then do it in C. Python elsewise simply because its harder to write crashing buggy code. Oh and PHP if you want a language that rewards you for writing sloppy code. :P
Also python integrates with C libs fairly easily, so you could always write your efficient pieces in C, then import their functionality in to python.


text:
Is there a guaranteed hash for every block?

Possible Duplicate:
Nonce size - Will it always be big enough?

My question may be misphrased, if so, I'll correct it if you let me know in the comments.
My understanding of mining is that the header is appended with some nonce and that is SHA256'd to get some hash, let's say: 7050a40746c695a220acb99c725ef66b29aa863707b17ba939c8bb1f5ec52b67
This happens until there are X number of consecutive 0's in that hash. Is there a guarantee that there will always be at least X 0's in a row for every block header?

There's no guarantee that you can solve a block just by adjusting the nonce.  But there are other things you can change in a block that also change the hash.
This question is pretty much an exact duplicate of your question.


text:
What will cause BTC/USD to shift substantially?

Possible Duplicate:
What factors affect the value of a Bitcoin?

It's been hovering at about $5/BTC for a few months now, slowly eeking upwards. What would cause a significant spike or drop?
Hacking and theft will, presumably, come down as more players get stable. As exchanges rise, liquidity should grow.

Major hacks or attacks on key exchanges or Bitcoin services can cause Bitcoin's price to fall quite dramatically.
Increase in popularity will slowly make the price rise. Another speculation bubble can cause the price to go up quickly.
Major investments made to Bitcoin can greatly increase the price.
All of those quick changes don't appear too likely at the moment. However, it is possible that the decrease in block reward that should happen roughly around the end of the year can double the price of Bitcoin, or make a lot of smaller miners drop out of the system.


text:
How does bitcoin find peers?
I've seen a few questions about this already and they talk in generalities. I'm talking about specifics. If I start the bitcoin client from scratch, where in the source code does it actually add nodes.
http://bitcoin.sipa.be/seeds.txt seems to be a list of known clients, which is fine, but where in source does it connect. If I wanted to create my own private network, how would I accomplish this?
If there's just one client on the network, is that client still doing all of the work that bitcoin does? Mining, etc.

The peer discovery process, in order of priority:

the client attempts to connect to peers in it's local peers.dat database
the client attempts to gain peers from one of four DNS-based seed nodes, hosted by Bitcoin developers
the client gives up

The peers.dat database is filled with information using addr messages, which connected peers use to exchange their knowledge of other existing nodes in the network.
If you want to make your own local nodes, you need to set discovery to 0, which will disable advertising of the peers as available for incoming connections. You can then forge connections using local DNS or simply ip addresses of other local nodes with the connect option. At least one of these will need to be connecting out to the wider network for you to be able to stay up to date, and to mine on using p2pool. More than one connection out is vital to the stability of your private nodes.


text:
How can I programmatically know when someone sends me Bitcoins?
I'm trying to set up a software system and part of it is knowing when someone sends Bitcoins to me automatically. I'm using node.js, if that matters to anyone.

You should try giving more details in your question - will you be using a single address, or generate then on the fly and use them only once? Are you planning on running bitcoind somewhere, or want to have a standalone application? The more you tell us about the constrains of your system the better the community can help you with a solution that is tailored to your needs.

BlockChain.info provides a push notification API:
 - http://blockchain.info/api_websocket

That looks very good. Is there also a quick way to take this information to see how many verifications it has?

Is it possible to do on my own? I mean how does blockchain.info get the info?

The BlockChain.info api looks cool but what if we want to use TestNet to test? Can we run a service like this on our own box? I was thinking of having a loop polling but wanted to know if there are any better ways.

You could poll the Block Explorer for balance of any Bitcoin address. For example, you can see the page of the address that appeared in the Genesis Block.


text:
Who made Gavin project leader?
I mean no disrespect to Gavin Andresen whatsoever. I think someone needs to be at the head of the project and Satoshi has stepped down / disappeared / gone back to the NSA / returned to his home planet / choose your conspiracy theory.
But why Gavin? What's the succession plan? What if Gavin gets tired of the project and chooses not to work on it any more? There certainly are core contributors, but exactly how is the "organization" set up? I know there's no actual "organization", but what I mean is the people in charge of the direction of the Bitcoin project.

You may want to search for a video of Gavin's talk from the NYC conference, where he addressed some of these points.

http://www.youtube.com/watch?v=0ljx4bbJrYE#t=2m35s is the talk Meni's referring to.  The production quality is pretty poor, but I don't know of a better copy.  At around 6m30s he starts talking about how he became the project lead.

Satoshi essentially named Gavin project lead by putting his contact info on bitcoin.org, giving him a copy of the alert key, giving him control of the SourceForge project, etc. Not many people have a problem with this, since Gavin has done a great job. I don't think anyone else in the Bitcoin community could have done better.
Gavin doesn't have exclusive control over many assets, so development can continue without too much trouble if he disappears without "naming a successor". Releases can even now be created and published on bitcoin.org without Gavin. bitcoin.org and the Bitcoin Forum are owned by Sirius, not Gavin. I have a copy of the alert key.
If Gavin disappears, I'd expect the project to continue reasonably well without a clear leader for a while before someone steps up to Gavin's responsibilities and is recognized by the community.

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


text:
How do I run a headless testnet on OS X?
I'm trying to develop some applications and need bitcoind, but can't seem to find a recent version. Posts seem to indicate that it's incorporated into Bitcoin-Qt, but I don't want to run a GUI just for headless RPC calls.
So how do I set up a testnet on OS X?
How to setup testnet-in-a-box on Mac OSX? seems like it would work, except I don't have the bitcoind command for whatever reason.

Ready to use distribution of bitcoind for Mac OS X doesn't exist, so you would have to build it from source code, here is the instructions for that: What are the steps in building bitcoind on Mac OS X 10.6?

You could also install Homebrew, then run the command brew install bitcoin then you will have bitcoind installed.


text:
How does Electrum make a keypair out of a seed?
Electrum uses a seed of 12 words to generate a keypair and then hierarchically generates addresses out of that keypair.
I know how to generate hierarchic addresses from a keypair, but what I don't understand is how Electrum generates a keypair from the seed. I understand the seed consists of words coming from a 2048 length wordlist, but after that it is unclear to me how it starts to generate the sequence of addresses.

I'd like to do the HD generation in either Java / C++ / Python or C#.
If I can understand the process, I might be able to reproduce it myself and generate hierarchical addresses from a seed.

EDIT:
A day later I find this Java implementation... Thanks for the answers!
https://github.com/harningt/atomun-mnemonic

Wallets created by Electrum 1.x have seeds containing 12 words (24 words is also possible for custom-created seeds). Given a zero-based array of seed_words of that length, this pseudocode calculates the master_private_key:
i = 0
while i < length(seed_words):
    # convert each word into an int in the range [0,1625]
    # based on the word's position in the sorted word list
    seed_ints[i] = lookup_seed_word(seed_words[i])
    i = i + 1

num_words  = 1626
num_words2 = num_words * num_words
seed_hex_str = ""
i = 0
while i < length(seed_words):
    # (hex8 converts an int into an ASCII string of
    # exactly 8 zero-padded lowercase hex digits;
    # % is the integer remainder operator
    seed_hex_str = seed_hex_str + hex8( seed_ints[i    ]
                    + num_words  * (   (seed_ints[i + 1] - seed_ints[i    ]) % num_words )
                    + num_words2 * (   (seed_ints[i + 2] - seed_ints[i + 1]) % num_words ))
    i = i + 3

unstretched_seed = ascii_string_to_byte_array(seed_hex_str)
seed = byte_array()  # an empty byte array
i = 0
while i < 100000:
    # sha256 operates on and produces byte arrays
    seed = sha256(seed + unstretched_seed)
    i = i + 1

master_private_key = byte_array_to_int(seed, order=big_endian)

In case you're wondering, it seems that the reason the seed_ints calculation looks overly complex may be to avoid infringing on a patent.
For comparison, wallets created by Electrum 2.x typically have seeds containing 13 words, however they will on occasion have fewer. (It's technically possible to construct seeds of nearly any length which will be accepted when restoring an Electrum 2.x wallet.) Here's the pseudocode which calculates a BIP-32 extended master private key:
# Electrum 2.x doesn't separate mnemonic words with spaces in sentences for any CJK
# scripts when calculating the checksum or deriving a binary seed (even though this
# seems inappropriate for some CJK scripts such as Hiragana as used by the ja wordlist)
if language is CJK:
    space = ""
else:
    space = " "

seed_phrase = ""
i = 0
do:
    word = seed_words[i]
    normalize_unicode(word, normalization=nfkd)
    remove_unicode_combining_marks(word)  # e.g. accent marks
    seed_phrase = seed_phrase + word
    i = i + 1
    if i ≥ length(seed_words):
        exit-loop
    seed_phrase = seed_phrase + space

seed_utf8 = unicode_to_byte_array(seed_phrase, format=utf8)

if hmac_sha512(key="Seed version", message=seed_utf8)[0] ≠ 1:
    fail("invalid checksum")

stretched_seed = pbkdf2_hmac_sha512(password=seed_utf8, salt="electrum", iterations=2048, output_length=64)
seed_bytes = hmac_sha512(key="Bitcoin seed", message=stretched_seed)

private_key        = byte_array_to_int(seed_bytes[0..31], order=big_endian)
chain_code_bytes   = seed_bytes[32..63]
master_private_key = create_bip32_extended_private_key(private_key, chain_code_bytes)

BIP-39, an alternative derivation technique, is similar to Electrum 2.x but not identical.

"seed = sha256(seed + unstretched_seed)" or seed = sha256(seed) + sha256(unstretched_seed))" ? Im unaware of a SHA256 method that takes two byte arrays.

You're right, it doesn't. The '+' was intended to convey concatenation. IOW, the original unstretched_seed is appended to the result of the last sha256 before its hash is taken in every iteration. For a more concrete example, see here: https://github.com/gurnec/btcrecover/blob/5d5432182f95def45929f91f8b9a5daa2ad21ba9/seedrecover.py#L391-L392

@MrJones FYI I fixed a mistake in the Electrum 1.x pseudocode: num_words was wrong. Sorry about that.

I confirm the patent-avoidance thing

authors: اکبر بختیاری


text:
How to generate a Litecoin Private key and correspondent Public Address in C#
I found this C# tool to generate addresses for Bitcoin (compressed and uncompressed):
https://en.bitcoin.it/wiki/Bitcoin_Address_Utility
https://github.com/casascius/Bitcoin-Address-Utility
It works perfectly for Bitcoin, but for Litecoin it seems not to work.
Any ideas how to use similar code to generate Litecoin Addresses?
Thanks

That's odd, since BAU's docs say that they ought to work with Litecoin. In the drop-down menu that selects the coin type, have you selected Litecoin?
Alternately, if you're willing to run an RPC node, you could use BitcoinLib, and call CoinService.GetNewAddress(String).
Generally, it's exactly the same as generating Bitcoin addresses, except that the version byte is 48 instead of 0.

I accepted your answer because of your Alternative suggestion of using CoinService.GetNewAddress(String). That sounds like a very good idea, since Bitcoinlib supports not just Bitcoin but other altcoins. Thanks a lot!
For the record - Selecting Litecoin in the Drop Down Menu DOESN'T WORK, it generates wrong addresses. it looks that Bitcoin_Address_Utility is just  working 100% for Bitcoin.

Bitcoin and Litecoin have different inner workings, so many of their parts shouldn't be interchangeable.
A short answer to your question could be: do you know C++ ? In this case, you could take a look at the parts of the reference implementation of Litecoin where the addresses are generated, and adapt it to C#.
Another answer would be to find an alternative library, independent of Litecoin reference implementation. One such implementation seems to be Litecoin-PHP-Library, that is a heavily commented PHP code, where you can find answers to your questions. Good luck.

Bitcoin and Litecoin have different inner workings, so many of their parts shouldn't be interchangeable. That's not really true. They're vastly similar.

Similar doesn't mean equal or interchangeable.


text:
Are there any online services available to exchange prepaid cards into BTC?
I live in the USA.
I would like to use prepaid cards to buy some BTC (less than $100USD)
I've tried trucoin.com and the wait time is enormous, 4 days since sign up and still haven't received an invite.
I've also tried circle.com but they do not currently accept prepaid options.
What other options does a prepaid card user have?

You can buy a Target or Walmart gift card and trade it for Bitcoin in https://cardforcoin.com/

I like them: https://cryptopay.me/ and recommend them, had never any troubles with them.
There are several not recommended, please make your own research

Besides using something like http://localbitcoins.com, you can try https://purse.io/ and buy stuff for people on amazon with your card and get bitcoins back.


text:
nLockTime transactions, how do they persist? Are they broadcast before they are valid?
If nLockTime transactions aren't added to the blockchain until the nLockTime is met, then aren't they just being stored in memory of the miners and is there a risk they could get "lost"?
I guess I'm just wondering how a long term nLockTime transaction can really persist. If I set it for 1 year in the future, and everyone restarts their node at some point during that time, isn't there a chance the transaction get's lost? Or would this require all nodes restarting simultaneously?
EDIT: Or are nLockTime transactions just held off network by the interested parties and then broadcast once nLockTime is reached? I read some things about DOS attacks with nLockTime transactions leading me to think that miners would not bother storing these at all in memory.

The release notes for Bitcoin Core (Satoshi client) version 0.9.0 states

Accept nLockTime transactions that finalize in the next block

So it will just discard other nLockTime transactions. Since most miners run bitcoind or some fork of bitcoind, it is unlikely that an nLockTime transaction will persist for a long time.

In other words: the responsibility of keeping a copy of the transaction and broadcast that when it's time, lies with whoever is interested in making the transaction (probably the recipient)


text:
A complete bitcoin implementation in Python?
I recently became aware that python-bitcoinlib is not a full bitcoin node implementation, but rather a set of tools to work with bitcoin-core cpp. I would like to know whether there are some fundamental issues with implementing a complete bitcoin node using python? Also if it were to be tried as a code-golf exercise (the shortest code to get the full node running) how many lines of code will it amount to in python ??

Performance-wise this would be bad idea, as Python dynamic programming language tend to use more RAM on data structures. It could be however interesting exercise.

@MikkoOhtamaa: Python is perfectly capable of handling the performance requirements of a Bitcoin node. The answers so far point to several projects that do this.

@GregHewgill: But none of those can serve as a complete replacement for bitcoin-core, right?

@user2277550: I don't see why not. There's no underlying reason why Python would be unsuitable for this purpose. It's certainly more than capable enough. It sounds like you're asking whether somebody else has already written in Python exactly what you have in mind. Maybe, maybe not. But it's possible to do so.

@GregHewgill: Links or didn't happen :)

@MikkoOhtamaa: The existing answers already have several links. I'm not sure what more you're asking for.

@GregHewgill: Ok thanks - seeing the answer now.

AFAIK, there is no fundamental issues with implementing a complete bitcoin node using python, there is even some cool projects of Bitcoin full node in Python

https://github.com/samrushing/caesure
https://bitcointalk.org/index.php?topic=94645.0

That strongly depends on your definition of complete. There are a number of implementations that implement parts of the Bitcoin node functionality. For example cdecker/pycoin has a solid network implementation, but does not include wallet management code and validation logic. richardkiss/pycoin on the other hand has some of the wallet logic, but lacks networking. Other libraries include:

vbuterin/pybitcointools
petertodd/python-bitcoinlib

But as far as I know there is no standalone client that includes a wallet as well as the networking code.

Check out Tinychain.
It isn't complete and will never inter-operate with the real Bitcoin network, but it is a "code golf" approach to implementing all the Bitcoin core ideas (validation, POW mining, peer-to-peer architecture, data structures like TxIn/TxOut/Block, etc) in Python.

There is a project, which is a complete bitcoin implementation in python.
The source code at https://github.com/csunny/py-bitcoin


text:
Can a hard fork effectively double the value held in bitcoin?
A hard fork necessarily means that two versions of the block-chain exist and value is held in both. Now realistically one of them should probably go down in value and the other increase or hold steady such that the total value held in them is roughly the same at the end of the day ( assuming a rational crypto-currency market). However assume that the market is undervalued and somehow the market decides that both the blockchains have the same value or that the new one is way more valuable than the older one, with the latter holding its value; isnt that equivalent to something like 4 billion dollars of value being created out of thin air? And also, how likely is that scenario, especially in the context of bitcoin classic....

"assume that the market is undervalued and somehow the market decides that both the blockchains have the same value": This is approximately as likely as the market suddenly deciding that Monopoly money has the same value as US dollars.

That's why I chose not to address it strongly. ;) The market constantly reevaluates itself. Being undervalued strongly ties into the estimation of future prospects. A hardfork surely would let these fall through the cellar floor.

My bad, I should've phrased it better. What I meant wasnt a case where the market suddenly decides that both are of the same value. It was more like the case where in the long run, one really takes off, whereas the other equilibrates near the original value.

I'm not an economist, but…
No, that's very unlikely.
Starting from your assumption that the network splits into two persisting blockchains*:

The number of active participants of each network is reduced. This reduces the utility of the network. → Negative effect on the value.
The amount of transactions that can be sent increases. This improves the utility of the network. → Positive effect on the value.
The shortterm security of both chains is reduced as hash power is spread to two chains. → Negative effect on the value.
The longterm security of both networks is reduced, as one or both of them become more likely to cease existing. → Negative effect on the value.
Unforeseeable reactions of various invested parties. → Unknown effects.

Shortterm:
I'm fairly confident that a project fork would throw the community into turmoil. Some developers might leave, some companies may be bankrupted, lots of users would lose money. The community would have to reorganize, work on governance, work out new goals, and rebuild teams. Blocks will slow down due to hash power splitting to two chains. The underdog may use this opportunity to completely redefine themselves, thus bringing their project back into the game. Development would slow down significantly for a while. I would expect each chain to have a lower value than the original chain, most likely the sum of both would fall well below the original chain's value.
Longterm:
I'm convinced that cryptocurrencies benefit so strongly from the network effect, that only a small number of them will be able to coexist, i.e. both blockchains would be competing for the same market share. Either they diversify to an extent where they appeal to vastly different userbases, or balance will at some point tilt, causing one side to take the lion's share. Even if the projects significantly diverge, one should end up much more widespread than the other. Should this schism have a clear victor quick enough, the winner, now improved in comparison to the original blockchain, could attract the bulk of the community, and rally. If they split without a clear majority and the schism drags on, it might become so ugly that both bleed support and go extinct.

*It's not clear that two chains would persist after a hardfork. The game theory seems to work out in a way that one chain would very quickly be abolished.

A problem you left out is that in case of a fork computing power has to be split across the forks. Due to the role proof-of-work has in bitcoin, that means each fork will be more vulnerable to attacks.

@kasperd: Good point, thanks. I've added something for that.

I agree with Murch on what would happen if we get a persistent de-facto fork of the blockchain; the sum of both would fall well below the original chain's value.
However, I don't believe we will ever get there.  I believe it's a common misconception to think we could ever get a split into "core-coin" and a "classic coin" (or XT coin) with those two being on somehow equal footing.  That won't happen.  The hard-fork is only reality when;

At least 75% of the hashing power signals support for the new chain rules
Some grace time period (28 days) have passed, allowing the remaining 25% to upgrade their software
Some miner actually mines a block that is not accepted by the old rules (that is, a block that is above 1MB).

And even then the coins won't be split; transactions will still be going into a shared mempool and they are likely to be included on both chains.  Now if the split is allowed to continue it will be messy as hell, some transactions going through at both chains and some only at one.  Some clever people will probably be doing double-spend-attacks to make sure to split their coins.  After a while freshly minted coins will be entering the chains, they will be valid only on the chain they are mined.
That said, I believe the hard-fork, when/if it comes, will be successful - the chain following the old rules will be abandoned, and the BTC value will go through the roof once the market realize that the much-feared-for hard-fork went smooth.
To initiate the count-down for the hard-fork, at least 75% of the miners have to signal support - but in reality the threshold is likely to be higher:

Miners depend on a high BTC value, hence they will only be willing to signal support for the hard-fork if it is overwhelmingly probable to be successful.  Last I heard, Chinese miners will signal support when it seems likely that at least 90% of the hashing power will support it.
Miners will have a very hard time selling their freshly minted coins if they mine at the "wrong" part of the fork - hence whatever minority is against the fork will be very quick on switching sides and support the "winning" side.
The "old" fork will for all practical purposes become unusable for several months, even if as much as 25% of the miners still will support it - the everage interval between blocks will be at least 40 minutes, the mempool will become overflooded, transactions won't go through, it will be a sinking ship for sure.

I'm not sure it's valid to assume that the hard-fork necessarily would go so smooth. I see three potential issues: 1) Miners retract support after support was signalled. 2) A steadfast minority of 10-15% refuses to switch chains. 3) As consensus is never reached, a frustrated majority attempts a contentious hardfork with 60-70% support. – E.g. even a 90%-10% split could get really ugly. Say, in the case of 10% small blockists: 90% of the miners accept big blocks, and 100% of the miners accept small blocks, perhaps leading to the checkpointing of a big block and 3).

#2 is a legitimate concern, not only due to "die hard smallblockers", but also due to folks who just don't care upgrading software. One can hope for the first big block to be mined just after difficulty recalculation, then the problem will become insignificant. I think #3 is unlikely, I can only say I strongly believe it won't happen. The minority will accept defeat, and miners won't vote for the proposal unless they expect success. #1, only if miners intend to sabotage, and they don't.

"once the market realize that the much-feared-for hard-fork went smooth." Why would anyone trust a system whose fundamental rules can be changed by a simple minor majority? What kind of "digital gold" guarantee is that? Most of the world has such a minor majority rule already.

As to "why would anyone trust a system whose fundamental rules can be changed by a simple minor majority?" - that's FUD.  There is a lot more to it than a "simple majority".  This debate has already been going on for several years (and it has been a heated debate for more than half a year already), lots of negotiations and compromises has been made, 75% miner approval is needed to move forward.  And, this is more about keeping "status quo" (keeping the limit well above actual block sizes) than to change something.


text:
Are there any attempts at creating ASIC for bitcoin mining?
I take reference to the Question here which compares ASIC with FPGA. In this question someone quotes a company called Largecoin that is said to be at the development of such an ASIC. However their web page does not really look promising. It rather looks like some investment seeking attempt. (Quote from the only content on the web page: "For more information about LargeCoin, visit largecoin.com")
I would like to know if there are any other attempts at building ASIC for bitcoin mining?

LargeCoin actually seem to be very close to releasing their first ASIC: http://www.reddit.com/r/Bitcoin/comments/qj9ov/somebody_please_perform_an_roi_on_the_30k/

Well, yeah, I know, so I didn't post it as an answer but rather a comment.

The closest thing to ASIC seems to be the BitForce series which has just been released and customers it seems are just begining to receive their first orders.
From the website:

Is your system based on FPGA or ASIC technology?
The BitForce processor card is a proprietary implementation of both
  FPGA and ASIC technology.

As far as I'm aware, the actual chip design won't be released, but it seems legit now that people have begun testing the potential.
http://www.butterflylabs.com/

BFL's first-gen products were FPGA based, the ASIC mention was either marketing speak, or a reference to the future product Bitforce SC which is indeed ASIC-based.

There are several ASIC devices reportedly under development:

OpenBitASIC.
Butterfly Labs BitForce SC.
LargeCoin which you mentioned.
Vladimir's company.

thanks for your answer. 1) I could claim to have triggered this development (1 month after my question)
2) This company seems to be serious. At the time when I asked the question their only product was FPGA - not ASIC. Lets wait until October.
3) No update since. Very scam-like.
4) Please read the thread. This really looks like another scam.
Although people seem to be very exited about ASIC, I hardly see that term ever used beyond marketing speech.

LargeCoin didn't take anyone's money. Usually when someone is doing a scam they take money. 4) I read some of it. Vladimir is a well-known member of the Bitcoin community. I don't know exactly what his plans are but I doubt they could be called a scam.

That's why I only said "scam-like". Besides: Do you really know that they didn't take anyones money? Maybe they still wait before they run... Maybe... who knows? Their website is the same static page since months.
And: Iv'e read Valdimirs posts too. Do you have another "proof" that he's the owner of LargeCoin besides these posts? It's not my intension to offend anyone, I'm just applying the necessary prudence in this this higly anonymized business.

@user1127914: Yes, I preordered from LargeCoin and they didn't take my money, other people reported that they preordered and they didn't take their money, and nobody reported that they took his money. This is the first time I've heard the theory that Vladimir and Largecoin are related, do you have any evidence? And, what anonymized business? The identities of both Ken Simpson from Largecoin and Vladimir Marchenko are known.


text:
What is the most effective way to buy bitcoin from swiss francs?
The most effective way I could find so far was Mt.Gox. The costs that are involved are still quite prohibitive. But this then boils down to the question: what is the most effective way to get your money out of [Insert your Exchage here]-exchange.
Is there any better way to convert your currency? (Swiss Francs in my case)

Voted to close as too localized.

@ripper234: How is that too localized? Swiss francs are a major currency (and even if not, this question would be of interest to a not insignificant user group for any currency).

@Thilo - because we have lots of similar questions, and it's not feasible to answer them all in a consistent manner. Also the answers will change with time, etc... don't won't to argue over it here though, it's just close vote, nothing major.

Switzerland takes part in the SEPA (Single Euro Payment Area); the Bitcoin exchanges that do SEPA transfers will probably be the ones with lowest costs for you.
I expect your bank will charge you for converting between CHF and EUR. If you want to convert often you may want to open a euro denominated account instead.

There is also BitStamp which lists CHF as a currency it will convert for trading (international wire).
See also the wiki page on selling bitcoins.


text:
Why isn't 'classic' Multi-Paxos Byzantine Consensus used for public Blockchains?
Any solution to the Byzantine General's Problem can be used as a consensus method to base a distributed ledger on.
Why then, did Satoshi Nakamoto choose for the super-expensive (in electricity and CPU cycles) Proof-Of-Work?
I can think of these reasons:

Proof of Work takes time, which means that blocks take time. (But nowadays this is actually a drawback?)
Miners are paid out by the PoW. (But couldn't this work in a Multi-Paxos environment as well, where basically all miners would like to become leader for the next round?)
A Proof-of-Work chain will still work if the network netsplits into two pieces. This will create separate blocks in each half of the network, actually being a problem when the two halves are joined again (because then one of the two chains is discarded, which, if the netsplit took multiple minutes before healing, means that people and external systems might have acted based on their now-invalid balances.)

Clearly these reasons are not good enough. So what real reasons are there to use Proof-of-Work over e.g. Multi-Paxos or another 'classical' solution to the Byzantine Generals Problem?

Isn't Byzantine generals problem unsolvable? https://en.wikipedia.org/wiki/Two_Generals%27_Problem

@croraf This is why all BFT systems, including Bitcoin, claim to be eventually consistent. That is: As long as some proper message in the very far future does arrive between nodes, it will be consistent. They are thus only solutions to this restricted version of the problem. The general version is indeed proven to be unsolvable.

Bitcoin isn't even eventually consistent, only probabilistically consistent (the chance that a particular state is final approaches 1 exponentially, but never reaches it).

Nakamoto Consensus has some properties that are superior to BFT algorithms. (It also has some properties that are inferior, but that's another story).
First, BFT algorithms assume a central authority picks who the participants are. NC, on the other hand, allows anyone to attempt to win the next round.
Second, BFT algorithms generally require 2/3 + 1 (e.g. 67%) of the participants are honest. NC sets a lower threshold of 1/2 + 1 (e.g. 51%). That's because NC's PoW prevents a node from broadcasting two messages at once.
Finally, NC has the interesting attribute that the moment a miner "wins", they also simultaneously choose the transactions they are going to include on the block. This means there is no window of opportunity for an attacker to attempt to influence the winning miner to break the rules.
Note that Paxos is not a BFT algorithm. Paxos solves for stop-fail failures. The worst a node can do is stop working. Paxos does not solve for "byzantine" failures, where a node can try to say two different things.

Consensus participants are not known ahead of time, so you don't know whom to listen to and whom to ignore. Also identities are extremely weak in Bitcoin (miners don't have identities at all, users usually just a cheap keypair), so sybil attacks (https://en.wikipedia.org/wiki/Sybil_attack) are cheap.

Proof-of-work creates a relation between a miners ability to vote on what the next block should be, and a real-world expense (electricity costs). You cannot spoof proof-of-work results, so you cannot spoof the network by pretending to do work that you didn't actually do.
If there was no cost to running a 'mining node' in the network, then what would happen when an entire Amazon server warehouse worth of nodes join the network? You need a method to defend against sybil/ddos attacks.
To answer your points:

taking time is essential, it means miners are working to solve the next block. Their investment is very closely related to the network security. More investment = more hashpower = more difficult to change the history = more security.
I think the leader in a multi-paxos environment could be paid something like a block reward
This is true, it sometimes happens and leads to an 'orphaned block'. In relation to your first point, shorter blocktimes actually lead to higher orphan block rates, due to a higher chance of two miners finding their own valid blocks within a short timespan of eachother.

In relation to Paxos, what I am reading about multi-paxos says that a leader node needs to be trusted, so it seems a level of trust is required in these systems. Paxos systems also hold a state, while the bitcoin blockchain is stateless, so that is a difference in security/failure modes as well.

Please don't edit spam to remove the links, like you did on this post. Doing so makes it harder to appropriately deal with the spam post and results in the spam existing on the site longer, along with giving the spammer the opportunity to revert the edit in order to remove any spam flags cast on the edited version (which they are likely to do, just because you removed the spam content). Please see: Should spam posts be edited? [Please ping me (@Makyen) once you read this, so I can delete it, as it has nothing to do with your answer here.]


text:
Read wallet.dat error?
I use BitcoinSharp with C#.net. I try to reading my wallet.dat (dont encrpyt). And some error : "The input stream is not a valid binary format. The starting contents (in bytes) are: 00-00-00-00-01-00-00-00-00-00-00-00-62-31-05-00-09 .."
Have any Idea ?
Thanks..

Can you reproduce this with a fresh test wallet? Perhaps you can post a link to such a wallet here, to help reproduce it? Also, perhaps Bitcoin SE isn't the best place to ask this - try contacting the developers of BitcoinSharp.

BitcoinSharp does not use the same format that the standard Bitcoin client uses for its wallet file.
BitcoinSharp simply serializes the Wallet object into Binary and writes it to a file whereas the standard Bitcoin client writes its wallet.dat file in a BerkeleyDB format, so the two are not compatible.
You could use something like pywallet to export the keys from wallet.dat and then manually add them to BitcoinSharp's Wallet object, but you won't be able to directly read a wallet.dat.

I am using serial&desirial wallet object into to file. Thanks..

Not sure I understand the comment, could you rephrase? It doesn't matter what method you're using to open or read the file, Bitcoin's wallet.dat and BitcoinSharp's wallet file are not in the same format - one cannot read or write to the other.


text:
What is the probability of forking in blockchain?
Is there any general formula that allows someone to calculate what is the current probability of having a chain fork?
I know that the probability of finding a new block is proportional to the difficulty target. Given that it's possible to have 2^256 different hashes (for simplification), finding a nonce that will yield a hash lower than target has probability of approximately P(m) = (2^256 - target)/2^256.
Given that a block will be mined within 10 minutes and considering that a delay of 2 seconds would be small enough for the newtwork propagation not being complete, that is, if two nodes find a block 2 seconds appart, there would be no time to notify the full network.
Here is when it gets complicated to me (statistics is not strong with me). What is the probability of the situation described above occur?
I think this is something related with a normal distribution, but I'm not sure.
My rational to find the probability of forking would be:
P(fork) = P(m1) * P(m2) * P(tdse)

Where P(m1) is the probability of node 1 to find a new block, P(m2) the same for node 2 and P(tdse) is the probability of both mining occur with a time difference small enough to not be propagated to the entire network.

Actually, it is not related to the difficulty at all, rather just related to the expected time until the next block is found.
Block finding is a Poisson process.
The probability of x blocks occuring in the amount of time we'd expect λ blocks occuring therefore is:

In ideal conditions, we expect one block per ten minutes, i.e. 600 seconds. Therefore in 2 seconds we'd expect 1/300 blocks occuring.
p(2|1/300) evaluates to approximately 5.54*10-6 which is about 0.000554%, i.e. we'd expect two blocks to occur within two seconds once every 180k blocks or every ~3.4 years.
More exciting are ten seconds which has a probability of about 0.00014, i.e. we'd expect two blocks within ten seconds to happen once every 7000 blocks, i.e. roughly every seven weeks.

Nice! Now I'm wondering how much time a block discovery takes to be propagated to the entire network.

@HenriqueBarcelos: Have a look at How long does it take to propagate a newly created block to the entire Bitcoin network and why?


text:
Help me understand Bitcoin analytics
I'm trying to use the Blocktrail API to look at the oldest Bitcoin addresses to create a info graph piece - besides looking at historical transactions, what else would be good for me to analyze?
\\ to be specific, what could I use analytics for with Bitcoin
- besides looking at addresses

Hi Lisa, I'm afraid that such an open question doesn't work well on Bitcoin.SE. Perhaps you should check out our [tour] and [ask] to get more information about how our site works and what kind of questions and answers we collect here.

What are you looking to analyze.

I'm particularly curious about analytics for addresses that include taint-of-taint data, specifically I'm wondering if its possible to extract useful information from an address that's interacted with coins 2 hops away from say, a betting site. I think this could have many implications for researchers looking to do some other kind of node/graph analysis as well.

authors: Временный Аккаунт


text:
University Bitcoin event ideas
Can you give me ideas for interesting Bitcoin-related events/projects that I could launch at my university in order to attract people to the club?

Anyone have ideas ?

You could:

Wear a Bitcoin shirt (people will ask ;))
Have a Bitcoin themed party in a student bar
Offer a Bitcoin meetup
Walk around on Campus with a sign "Ask me anything about Bitcoin"
Start a Bitcoin student club
Convince a Campus shop to accept Bitcoin
Convince a food delivery service close to campus to accept Bitcoin
Offer a competition where you offer a price in Bitcoin
Organize a Presentation/Lecture/Panel about Bitcoin
Write an article for your student newspaper/newsletter
Organize a viewing of one of the Bitcoin documentaries on campus


text:
Get scripthash for known scriptPubKey in PHP
I have to query addresses in ElectrumX server. How do I generate scripthash for a known scriptPubKey in PHP?
Example address:
array (
  'isvalid' => true,
  'address' => '1MUz4VMYui5qY1mxUiG8BQ1Luv6tqkvaiL',
  'scriptPubKey' => '76a914e0ad60c897901128662623c500a4a6079e99cd3e88ac',
  'isscript' => false,
  'iswitness' => false,
)

I tried:
hash('sha256', hex2bin('76a914e0ad60c897901128662623c500a4a6079e99cd3e88ac'))

But it seems to be wrong.

I found the solution replicating https://github.com/janoside/btc-rpc-explorer/blob/master/app/api/electrumAddressApi.js
$scriptPubKey = '76a914e0ad60c897901128662623c500a4a6079e99cd3e88ac';

$addrScripthash = hash('sha256', hex2bin($scriptPubKey));
$re = '/.{2}/';
preg_match_all($re, $addrScripthash, $matches, PREG_PATTERN_ORDER, 0);
$addrScripthash = implode('', array_reverse($matches[0]));

print($addrScripthash);

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


text:
bitcoind inconsistent authentication error
I am using a Linux computer.
The issue I am having is that sometimes I have to use "kill -s 9 (bitcoind pid)" and restart bitcoind using "bitcoind -txindex" because bitcoind will sometimes not let me use "bitcoind stop". For example:
brian@brians-lair3:~/Desktop/VH2_apache2/host02/btc15$ bitcoind stop
error: incorrect rpcuser or rpcpassword (authorization failed)

This happens after bitcoind has been running for a few hours or so.
It also locks me out of bitcoin-cli:
brian@brians-lair3:~/Desktop/VH2_apache2/host02/btc15$ bitcoin-cli getinfo -rpcuser=b -rpcpassword=a
error: incorrect rpcuser or rpcpassword (authorization failed)
brian@brians-lair3:~/Desktop/VH2_apache2/host02/btc15$ bitcoin-cli getinfo
error: incorrect rpcuser or rpcpassword (authorization failed)

Even when I specify the correct password and username it doesn't work.
Initially when I start bitcoind though, I can use bitcoin-cli:
brian@brians-lair3:~/Downloads/DownloadsArchive$ bitcoin-cli getinfo
{
    "version" : 90300,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 352549,
    "timeoffset" : -1,
    "connections" : 26,
    "proxy" : "",
    "difficulty" : 49446390688.24143982,
    "testnet" : false,
    "keypoololdest" : 1421427760,
    "keypoolsize" : 101,
    "unlocked_until" : 0,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00001000,
    "errors" : ""
}

Also here is my bitcoin.conf:
rpcuser=b
rpcpassword=a
txindex=1
server=1

here is debug.log, its at this link:
1. goto 66.42.220.205:18809 (its a website) type that in URL box
in a web browser

2. download debug.log

My question is can I prevent bitcoind from eventually coming to a point where I have to restart it using the command "kill -s 9 (pid)" and "bitcoind -txindex", or can I prevent it from coming into a state where it wont let me interact with it? If I can prevent this, how do I?
Also I need to use -txindex because it keeps an index of transactions and I need that for payment processing.
Thanks in advance!

I will update bitcoin and post the contents of debug.log

Odd. Is bitcoin.conf changing between bitcoin starting and when you have this problem?

From what I've seen bitcoin.conf hasn't changed. Also, the bug might have been patched in bitcoin 0.10.0 because from what I've seen, bitcoind hasn't rejected connection from bitcoin-cli since I updated bitcoin.

The error has happened again where bitcoind fails to authenticate connections correctly, even if you are unsure of an answer post what you can, my bitcoin payment processor will fail to work properly if bitcoind randomly denies access.


text:
Is the authentication system of the Bitcoin <-> SMS service PHONECO.IN adequate?
@osmosis made me aware of PHONECO.IN, which makes it possible to send Bitcoins via SMS. My question is whether their authentication system is adequate. From their website:

PhoneCo.in is designed to be easy to use and secure.  The server which processes your text message communicates with a separate server processing the bitcoin transaction.  The data from your text message is sent using AES-265 encryption and is signed using HMAC-SHA1.  This combination of security measures makes it very difficult to initiate a PhoneCo.in transaction in any way other than using a cell phone, as any requests to the bitcoin server must originate from the text message processing server.
We require you to reply with a 5 character confirmation code within 5 minutes when sending a payment.  This is necessary to verify that your phone has initiated the payment request (and that someone isn’t spoofing your phone number when contacting our server).  Spoofing another phone number is illegal in the United States and punishable with fines up to $10,000.  If you receive a confirmation code for a payment you didn’t initiate, contact us so we can help track the offender.

the domain for that service is returning a "It has been reserved on gandi.net and parked as unused" at this time

@barrymac Should I delete the question?

seems like the service is definitely history, but maybe you could re phrase the question , it's still useful information for developers of a replacement

I think it is probably adequate for its intended purpose but not adequate for managing large balances.
The biggest problem is the risk of compromise or theft of your phone or phone number. Anyone who obtains physical access to your phone while it's unlocked (or who is able to unlock it) can look through your text messages and can transfer your Bitcoins to themselves. The Bitcoins are effectively completely untraceable and permanently lost at this point.
The lack of a way to secure your account with PhoneCo.in without your phone is, in my opinion, a serious problem. What if I can't find my phone but might just have left it a friend's house? Am I supposed to disable my phone with my provider only to re-enable it in twenty minutes when I find it? Or am I supposed to have a 20 minute window in which someone can break into my phone and steal my Bitcoins? (Will a mobile company shut off your phone immediately even at 3AM?)
If your phone is lost or stolen, you have to have it disabled immediately -- even if it's locked, even if you might find it in a few minutes.
Another problem with the accounts only being associated with a phone number is that I have to trust my mobile provider. If I lose my mobile account for any reason, I lose my coins too. If my phone number is erroneously transferred to someone else, they get my Bitcoins or at the very least, I cannot get them. If my mobile provider suddenly decides I broke some rule and they cancel my contract "for security reasons", how can I prove to PhoneCo.in that it's my account?
So, the service is simple. It's convenient. And its security is about comparable to a physical wallet (that can also be lost or stolen).

It looks good to me. By entering confirmation you prove it's your number and you can additionally protect your account with a password.
You should not let others access your phone. If you do, you should delete relevant messages to prevent them seeing your password.


text:
Finding Transactions with seldom used opcodes for testing
I'm trying to implement a script evaluator and would like to get some real testing data from the blockchain (testnet or mainnet). Are there transactions whose input scriptSigs combined with the previous transaction's scriptPubKey use any/all of these op_codes? I'd like to compile a collection of such transactions as test vectors.
98: op_ver,
101: op_verif,
102: op_vernotif,
107: op_toaltstack,
108: op_fromaltstack,
109: op_2drop,
111: op_3dup,
112: op_2over,
113: op_2rot,
114: op_2swap,
115: op_ifdup,
116: op_depth,
119: op_nip,
120: op_over,
121: op_pick,
122: op_roll,
123: op_rot,
125: op_tuck,
139: op_1add,
140: op_1sub,
143: op_negate,
144: op_abs,
146: op_0notequal,
147: op_add,
148: op_sub,
154: op_booland,
155: op_boolor,
156: op_numequal,
157: op_numequalverify,
158: op_numnotequal,
159: op_lessthan,
160: op_greaterthan,
161: op_lessthanorequal,
162: op_greaterthanorequal,
163: op_min,
164: op_max,
165: op_within,
168: op_sha256,
170: op_hash256,
171: op_codeseparator,

Just to make sure I'm understanding, you'd like a compiled list of transactions which have these OP_ codes in their scriptPubKey? Would you prefer a spreadsheet and what info do you exactly need? TXID and ASM?

I would like transactions which spend utxos with these op codes either in the scriptPubKey or redeemScript.

I believe the early blocks of testnet contain a bunch of unusual transactions as a sort of test suite.  So that might be one place to start looking.

@JimmySong I wrote this small PHP script which I believe should work, but after running this overnight for 12+ hours I quickly realized this is quite inefficient and will likely take too long. Perhaps someone with SQL knowledge can utilize this to obtain the required info?

@NateEldredge, I checked the first 400 or so blocks of testnet and did not find anything that uses any of these script codes.

@JimmySong: Okay, sorry about the wild goose chase.  Of course, you ought to be able to manually create and spend some transactions like this on testnet, which may be more expedient than writing the code to search for existing ones.

A slightly bigger search yielded some interesting tx's on testnet. I'll post them as my own answer.

I did some digging with a parser I wrote and found 6 transactions that test a lot of the op codes:
efdf1b981d7bba9c941295c0dfc654c4b5e40d7b9744819dd4f78b8e149898e1
9aa3a5a6d9b7d1ac9555be8e42596d06686cc5f76d259b06c560a207d310d5f5
c5d4b73af6eed28798473b05d2b227edd4f285069629843e899b52c2d1c165b7
74ea059a63c7ebddaee6805e1560b15c937d99a9ee9745412cbc6d2a0a5f5305
e335562f7e297aadeed88e5954bc4eeb8dc00b31d829eedb232e39d672b0c009
dc3aad51b4b9ea1ef40755a38b0b4d6e08c72d2ac5e95b8bebe9bd319b6aed7e

These are all on testnet and test a very large number of the OP_CODES I requested. Here are still ones I'm looking for:
op_reserved
op_reserved1
op_reserved2
op_ver
op_verif
op_vernotif
op_2rot
op_2swap
op_1add
op_codeseparator

That'll be hard. OP_RESERVED, OP_RESERVED1, OP_RESERVED2, OP_VER, OP_VERIF, OP_VERNOTIF all immediately cause the script to fail, so they can't occur (unless in an unexecuted IF branch) in a valid spend. OP_VERIF and OP_VERNOTIF even cause failure when in an unexecuted IF branch.

Thanks @PieterWuille, I was confused about that. So it's a lot like OP_RETURN but for IF branches? I guess I just need the last 4, then.


text:
Why do you use Bitcoin addresses instead of public keys?
Why do you hash the public key twice? Are there security benefits to abstracting away from the public key? Is it because the address can represent multiple things? I'm missing something.
Could you theoretically send bitcoins directly to the public key?

:/ this is not a well formed question. what are you talking about? the fact that the key is hashed?

The fact that you hash the key twice, with SHA256 and RIPEMD160. Why go through the process? I'm working through Mastering Bitcoin, and he didn't explain very well why we need addresses.

it's it becasue it's some kind of special encoding that removes l and 1, something like that, to make then easier to read

It's just to make them easier to read? So, if that's the case, could you theoretically send bitcoin directly to the public key instead of the address?

maybe. how would you get the private key in isolation?

@s.matthew.english: Base58Check is just an encoding to present large numbers in a more readable fashion. It can be applied to Public Keys just as it can be to addresses.

The double hash is to protect against length-extension attacks. There's no reason to think you'd be vulnerable to such attacks, but it's a cheap way to ensure you don't even have to think about it. There is a slight security advantage in that the public key can be kept secret for longer, if desired. As stated below, Satoshi use a hash to keep the address as short as possible.

Yes, you could send bitcoins directly to the public key: in fact, both Pay-to-PubKey (P2PK) and Pay-to-PubKey-Hash (P2PKH) were introduced in the first Bitcoin release.
IIRC, P2PK is still used for Coinbase transactions sometimes, today.
P2PK transactions are slightly bigger for outputs but significantly smaller for inputs.
One advantage of P2PKH is that addresses are shorter than public keys. This allows addresses to be represented with 34 characters in Base58check.
If there were a standard to present public keys in Base58check, they'd probably have 51 characters. Arguably, it is easier to type a character jumble that is only 34 characters than one that is 51 characters.
But really, addresses get used because there is a standard for them and there is none for public keys. Why that is so, I don't know.
All credit to Pieter, who has provided the knowledge to amend my errors. ;)
Also see this related question: Why does the default miner implementation use pay-to-pubkey?

WIF is a format for private keys, not addresses. I also have never seen a standard for P2PK addresses.

@PieterWuille: Corrected WIF to Base58. I don't get your comment about "P2PK addresses"?

You say "public keys (51 characters in Base58), but AFAIK no standard exists to encode public keys as base58.

@PieterWuille: Wouldn't it be the same length as a private key because it's also a 256 bit number?

Well, yes, it would be, but that seems an irrelevant hypothetical. The biggest reason why people don't make P2PK outputs is that there is no address standard for it. You can argue why such a standard does not exist (as your answer points out, size is one reason), but you're skipping a step.

@PieterWuille: I guess I have too much half-knowledge. :p

@PieterWuille Are there any other reasons?

Compressed pubkeys weren't known when P2PKH address types were defined (so it'd be 95 base58 characters). 2) Higher cost to the sender. 3) Longer opportunity for hypothetical ECDLP attackers (which need to full pubkey).

Without checksums and prefixes a compressed pubkey is 33bytes, 45 bytes base58 encoded, vs 87 bytes uncompressed.   The ECDLP attack prevention is the best reason.   Without the pubkey, you basically have nothing to attack.

As @Murch correctly pointed out it is indeed possible to send bitcoin to either a public key or to the hash of a public key.
The original motivation for using hashes of public keys was to shorten the size of the address. Public keys in their uncompressed form are 64 bytes long whereas RIPE-MD outputs 20 bytes (+5 bytes of checksum and version).
Interestingly Satoshi did not know that public keys could be compressed to 32 bytes +1 bit (Why does Bitcoin support both compressed and uncompressed keys/addresses?) and thus chose hashes as a way to get compressed addresses.
The security implications are interesting:
Unlike public keys, hash functions like SHA-256 and RIPE-MD are believed to be quantum resistant. A quantum attacker could thus efficiently retrieve the private key for any Bitcoin public key but not for a P2PKH address. However, whenever a transaction spends from a P2PKH address it reveals the public key as part of the script.
On the other hand the total number of possible address is 2^160 whereas the total number of public keys is roughly 2^256. Theoretically this means that addresses are less secure than public keys against a brute force attack. Obviously, a brute force attack is completely infeasible for either type of address.

@benehsv your response is useful but the last point your make appears to me to be false however. You say PS2PK is harder to attack than PS2PKH. I think it is the opposite. With PS2PK the length benchmark is indeed 2^256. But with BTC addresses you don't just need to crack the BTC address back into a public key (2^256), that serves no purposes unless and until you then crack the public key back into its private key input for the EC curve (2^256). So actually the length benchmark is 2^(256+160)! Hence p2pkh is way more secure and complex to crack

@RodrigueAfota I am not sure that I agree. Say there is an address addr=H(g^(x)). The attackers goal is to find an x’ such that H(g^x’)=H(g^(x)). This x’ can be used to create a signature to spend the coins from addr This doesn’t meant that x=x’. If the RIPMD+SHA256 indeed have 160 bit security then the best attack runs in time roughly 2^160. If there are attacks on RIPMD the the best attack would be reduced (e.g. a quantum computer can do this in time 2^80). However I forgot to mention that the best classical algorithm for solving the discrete log problem already runs in time 2^128.


text:
Bitcoind crashes directly after starting
I'm am trying to solo mine. My first problem is when I try to launch bitcoin client as server with guiminer I get this error
Invalid -rpcallowip subnet specifications.* valid are a single ip.

I looked around and it seems that I need to open bitcoind and change my rpcallowip from what I understand.
My problem then is, when I try to open bitcoind, it pops up for 1 second then crashes. I have tried to run it as admin, I have downloaded a new wallet, but I couldn't get it to work.
From what I have seen my guess is it looks like rpcallowip=192.168.0.* I have seen I need to change it to rpcallowip=192.168.0.1/24. The problem is I don't know where to change it. Also I don't know if this is even the problem. I am trying to take this one step at a time. .
I thought it was in bitcoin-di. And like I was saying every time I try to load it, it crashes.
My goal is to get guiminer to solo farm with bitcoin core as my wallet. I thought it would be an easy process.
I'm on windows 8.1 with bitcoin core v0.10.2. Using guiminer. I set up with slosh pool and got that to work. My gpu is not strong enough to do any good tho so I figured I would give a shot with solo.
I'm not sure of I'm way off. Where so I go to change it?
Thank you for the response.

Are you specifying several IP's? if so, use several rpcallowip= entries. In general, they should look like rpcallowip=127.0.0.1  or rpcallowip=192.168.0.1/24

Well I figured it out. I had to find my bitcoin.config file. I opened it with note pad and changed rpcallowip=* to rpcallowip=192.168.0.1/24
I was trying to do that in bitcoind. Thanks to the guy who replied and thanks to whoever edited my post :)

authors: เอกพจน์ ศิลลิ


text:
How to cancel the callback url registered on blockchain.info
So i was testing the Blockchain receive API, and during the first trial, I had a typo on the callback url.
Does that mean blockchain.info will retry to call that bad url 1000 times before it finally gives up ?
Is there a way to cancel the unwanted callback registered on blockchain.info ?

Does that mean blockchain.info will retry to call that bad url 1000 times before it finally gives up ?

It would appear so, and I can't see a way to cancel it, besides creating a page at that url with the text '*ok*'
To see what requests it's made already, try looking at this page and putting the bad url in the Check Callback Response Log form.

Too bad It was domain name typo.