text:
What is the cheapest way to deposit money into a Bitstamp account from the US?
What is the cheapest way to deposit money into a Bitstamp account? They offer a number of ways, but what is the easiest for someone in the US?

I spent a long time researching this very question a while ago before buying my first bitcoins thinking that Bitstamp is the cheapest way to buy bitcoins (fee wise).  I ended up concluding that the cheapest way to deposit money in a Bitstamp account from the United States is with Ripple, which allows you to bypass the $15 wire transfer fee that it would cost to transfer money the old fashioned way.  However, I ended up going with Coinbase to buy my bitcoins rather than doing this.  I'll explain why:
In order to buy bitcoins this way using Bitstamp, the process is rather convoluted.  That alone is the first reason.  The second reason is that once I added up the fees, it was actually more expensive with bitstamp because you're not just paying Bitstamp's fees, but also the fees to transfer money into Ripple.
If you still want to do buy bitcoins using this method, here's how.
1) Setup a Ripple account.
2) Fund it with SnapSwap.  Fees:0.99% + $0.30.
3) Send the money to Bitstamp using Ripple.  The deposit money page when you're logged into Bitstamp will have the Ripple address to send money to in order to fund your account.
4) Buy bitcoins with the newly funded account.  Fees: 0.5%.
Cumulatively, the fees add up to 1.49%, excluding the $0.30 fee.  The fees that SnapSwap tack on negate the advantage of the relatively low fees that Bitstamp uses.
So if you're looking for a cheap exchange, since you live in the United States and thus cannot use SEPA, Bitstamp unfortunately probably won't work for you.  Here are your other options:

CampBX.  An Atlanta based exchange that has a fee of 0.55%.  As far as cheapest way to buy Bitcoins in the United States, this is probably your best bet.  Their website appears to be down right now, however.
Coinbase.  Not the cheapest option, but it may just be the easiest option.  That's why I choose Coinbase, I got frustrated with the hoops one has to jump through to buy bitcoins on other exchanges.  Coinbase has a 1% fee plus a bank fee of $0.15 when you're buying and selling bitcoins, the real advantage is that as far as I've been able to tell, they're the only ones that let you buy bitcoins with an old fashioned bank transfer.  The price is locked in at the time when you buy bitcoins, and you get them five business days later.

Alternatively, if you live in an area where people are selling bitcoins in person, you can buy bitcoins directly from someone who already owns them.  Localbitcoins.com is the place where you can check to see if anyone near you is selling bitcoins.

Is SnapSwap available for other countries like Singapore?

For some reason StackExchange never emailed me to let me know about your reply, Pacerier, so here's a rather late reply since I just happened to be checking up here.
As far as I can tell, you're out of luck with SnapSwap if you live in Singapore, unless you can get Euros fairly easily.  They do have a European version of the site here: https://snapswap.eu/, but I haven't been able to find an Asian version of the site.

Just edited this to remove the MtGox option since they went bankrupt.

Evan helped me greatly with his extensive analysis of Coinbase.  I just bought my very first bitcoin ever, using Coinbase from my iPad while sitting here at a coffee shop in Colorado.  Here are some additional insights while they are still fresh in my mind.

I set up a new checking account at Wells Fargo yesterday morning specifically to put a guard rail around my bitcoin transactions. This was because the Coinbase web page required me (Nov 2013) to send them a routing number and account number, but I did not feel comfortable doing this with my regular checking account. I funded the new Wells Fargo checking account with $300 that I paid with six 50-dollar bills.
I went onto the Coinbase website about an hour later, and entered my new routing number and account number. There was a small snag, because Coinbase was initially unable to verify the existence of my new WF account. The Coinbase site informed me that it would try to deposit two small amounts of cash into my new WF account over the next few days, after which I could verify to them the amounts of the two.
This morning (24 hours later) I noticed that a 19-cent deposit and a 7-cent deposit had been made overnight to my WF account. I entered this info on the Coinbase verification tab, and got immediate confirmation that this was successful.
Coinbase also required me to enter a phone number, and I entered my iPhone number. The site then required me to enter a code that it said was available by SMS. I had no idea what SMS even means, but there was a tab I could click to request a phone call from Coinbase to read me the required code number. After I clicked the tab, my iPhone got a phone call from San Francisco about 20 seconds later. A robovoice read me the code number slowly and clearly, and I was able to type it into the Coinbase box. I got a Coinbase confirmation alert immediately.
I then entered a buy for one bitcoin, with a price of $289 and a $3 transaction fee. The website confirmed the pending buy, and gave me an alert that the one bitcoin will appear in my Coinbase account about 7 days from now. So far, so good.....

The question explicitly asks about depositing money to Bitstamp, while you describe the procedure of depositing money to Coinbase, probably in order to answer the question "What is the cheapest way to acquire Bitcoin from the US?" instead. So, unfortunately, I am afraid you are missing the point here.


text:
Does bitcoin.conf expand environment variables?
I would like to store my Bitcoin RPC passwords and usernames in environment variables, like:

rpcuser=$RPC_USER
rpcpassword=$RPC_PASSWORD

Is this supported in bitcoin core? Can environmental variables be parsed from my bitcoin.conf file?

Very bad idea! Why should you do such a thing?

Why is it a bad idea?

I don't think this is a bad idea, but I do think that this is an XY Problem.

This would be great to have. I use docker to host my bitcoin node and I would like to be able to have docker inject environment variables depending on production/dev etc. Have you found how to do this yet?

It's been awhile. At the time, I ended up generating the config file with the values rather than using envvars, as I found no other way to do it.

No, bitcoin core does not expand environment variables in bitcoin.conf.
See here to see how options are parsed.
You can expand environment variables as arguments for bitcoind:
$ bitcoind -rpcuser="$RPC_USERNAME" -rpcpassword="$RPC_PASSWORD"

source: Stack Exchange

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

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

sort: votes


text:
Is it feasible to use the Blockchain technology without the Bitcoin?
Every once and a while, I step into some article like this one: Forget Bitcoin -- What Is the Blockchain and Why Should You Care?.
I've been hearing a lot of blabbering about companies to begin using the Blockchain technology for book keeping, for example, but making no use of Bitcoin at all.
I wonder: how is it possible to separate both things?
I mean, the aim of Satoshi Nakamoto was to create a decentralized coin that would supress the need of a trustworthy third part, which operates over the Blockchain.
The main aspect of the Blockchain is that it's a decentralized network, working on a peer-to-peer basis, no servers, no clients, only peers. The only reason someone would contribute to the building of the Blockchain is the monetary reward in form of mined bitcoins.
How could a company make use of the Blockchain? How would it pay someone to do its book keeping (or whatever) without payments in crypto-currency?
I see that this might be a rather wide question, but I'd be satisfied with only one example of how could it be possible to use the Blockchain technology without Bitcoin (or similar crypto-currencies).

I think you will find this of interest and it might answer your question (it answers a similar question).

Blockchain by definition is a data structure, in that sense we can and already have decoupled it from Bitcoin.  There are many alt-currencies that implement blockchain as a data structure and a data store.
Ethereum is building a blockchain based application platform.
Storj is an example of blockchain technology that also is trying to create a blockchain for data storage.
The SAFE(Secure Access For Everyone) network is attempting to build an entire computing platform built on a blockchain.
The key is incentivizing some form of participation by providing a service. On the Bitcoin blockchain the service being provided is the ability to send value globally very quickly.  Thus the reward that was created is financial.

I don't think that this answers the question. While, it is a data structure the incentivizing to support this structure in a decentralized pseudoanonymous way is accomplished with some form of payment (digital token that has some value). All of the examples mentioned provide payments in crypto-currencies (Ether, StorjCoin, SafeCoin). Thus there are alt-currencies with blockchains that store data but all of them also have a crypto-currency reward for the incentivization. E.g. StorJ doesn't incentivize participation with a service to the people that farm (mine) it... it provides StorJCoin.

To start with a softer example, Amazoncoin used by Amazon.com is moving into other uses for blockchain tech. Although it can be bought, sold, gifted, etc, its main purpose is to save money within Amazon itself, eliminating the need for bank transfers from one region to another which can be costly and also less secure. That scratches the surface.
BlockChain tech is now being implemented into internal banking systems that run their own blockchains to avoid fees associated with moving money regionally, quicker transactions, and a more secure and transparent ledger. It's rumored that even stocks will soon be using block chain tech (there may be a few active examples already). Here are some links that I think will get a little closer to the answer you are looking for. They tend to be a little vague, as banks are not in a hurry to share their internal operations, but give these a quick read, and follow links that are similar and you will see some of the many applications blockchains have.
Citibank mentioned in one of these already outdated articles has secured another sponsorship spot in the upcoming Consensus 2016 in March, happening in New York City.
Info on Citibank and others researching blockchains
http://www.forbes.com/sites/laurashin/2015/09/09/visa-citi-nasdaq-invest-30-million-in-blockchain-startup-chain-com/
Lastly, one of the companies that is creating these internal use enterprise class blockchains
http://chain.com/
There is a lot more out there to read, just pluck some key words and names from these articles and search them.

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


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

Your bitcoins will appear when you're done synchronizing. Bitcoin Core first has to catch up with 4 years of transaction history before it can verify current transactions.

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


text:
What is the maximum amount I can send with "sendmany()"
If I use the sendmany(); function is there a maximum of the output amount?
Example:
The maximum would be 0.01 BTC

data={'address1':amount1,'address2':amount2};

amount1+amount2 = 0.02 BTC

-> But then it would be above the maximum.

Thanks.

Are you asking whether you can send more than the Bitcoin contained within a single output, or whether the combined Bitcoin can exceed the Bitcoin in your wallet?

The maximum output amount is the full wallet balance minus any transaction fees, many inputs up to and including all that have a positive balance can be combined to create the utxo set used in the transaction.

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


text:
Best OS for cold storage
I want an OS which can be easily disconnected from all hard drives (just uses USB) and can be booted from usb stick, also secure enough and disconnected from internet by default (or something I can easily disconnect from Internet forever).

Use TAILS Linux. From the website:

Tails is a live operating system that you can start on almost any computer from a USB stick or a DVD.
It aims at preserving your privacy and anonymity, and helps you to:

use the Internet anonymously and circumvent censorship;
  all connections to the Internet are forced to go through the Tor network;
leave no trace on the computer you are using unless you ask it explicitly;
use state-of-the-art cryptographic tools to encrypt your files, emails and instant messaging.

Even Edward Snowden uses it.

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


text:
tiny-secp256k1 and ECDSA signing determinism
I noticed in bitcoin when using the tiny-secp256k1 library to sign the signature for a signature hash of an input; the signature is always the same.
However, the signature is always different in other ECDSA-Secp256k1 libraries. (I'm using one by nordic semiconductors.)
Do I misunderstand something? Is there a difference in the signature algorithms?
I read something about randomly and deterministically calculating the k value; should it matter if it is random or not? Or is there possibly extra encoding done after the signature hash is signed in Bitcoin Secp256k1?

The secp256k1 library uses RFC6979 to generate deterministic nonce values (k). It essentially takes the hash of both the private key and the message being signed in order to get k. This means that signing the same message with the same private key multiple times will always result in the same signature.
Other libraries may not do this. For example, ECDSA only requires that k be a random integer (or rather that k is indistinguishable from random). Therefore, some libraries will simply generate a random k and use that. RFC 6979 is another way to generate a k that is indistinguishable from random, assuming that the hash function used is pseudorandom (meaning its output is indistinguishable from random). The hash function used by Secp256k1 is HMAC-SHA256 which is considered secure.

Thanks
So basically other libraries that do not deterministically generate k but use a random k should still be able to produce a valid signature that would be accepted by the network?

@MandelDuck Correct. It's not possible to enforce that signatures are deterministic (if you could figure out whether they were, you could also learn the private key), so ECDSA (and all EC based signatures schemes like Schnorr and Ed25519) does not have deterministic signatures. Individual implementations can choose to be deterministic, but that's a purely local unobservable implementation detail.

thanks guys thats good to know, makes perfect sense

@MandelDuck Please mark Andrew's answer as a valid answer so this will get marked as answered.


text:
Transaction ID not found- Status still unconfirmed after a month?
I did a transaction back to my bitstamp account on 23.02.2016 but it has not been received. Transaction ID:
1886e0c49ba43a842043fc84358a05d3faf69468c1547e1d2ef3e030b929f834

I do have the blockchain located on an external hardrive since it takes up so much space. Any help on how I can get the transaction to go through?

Which wallet software are you using? Bitcoin-Core?

After 72 hours the transaction will get purged from the mempool if no miner has picked it up. Try resending the funds and include a transaction fee so that the miners will expedite your transaction.


text:
Is equihash/scrypt suitable for pooled mining?
A "sequential memory-hard" PoW scheme cannot be parallelized effectively thus I imagine you also can't distribute solving the puzzle between participants in a pool? How does that work with scrypt then - for instance how do litecoin mining pools work?
Correct me if I am wrong, but equihash is "just" memory-hard. I understand you are solving a generalized birthday problem among randomly generated bitstrings. But my question here is: how does the pool verify you are actually doing meaningful work. Like with a "traditional" PoW you submit partial solutions that don't match the network difficulty but still have some difficulty "attached" that prove you did some work.
For equihash I believe there is no "partial" solution, either you find the inputs that xor to zero or you don't. What am I missing?
Are there any zcash mining pools out there yet? How do they ensure "fairness"?

First part of my question can probably be explained: one scrypt calculation is hard to be sped-up using multiple threads, but you can always do multiple of them (with different nonces). Each of them still needs lots of memory. So basically multiple people calculate completely
different scrypt invocations.
For the second one I probably don't understand how zcash exactly utilizes equihash and I'd be glad if someone can explain that.

I should have read the Equihash paper.
Basically the PoW is still one big loop going over a 160-bit nonce, but in the body there is the solving of the generalized birthday problem using Wagner's algorithm.
The parameters are pseudorandomly generated (using a hash function based on previous block and nonce) and at the end the solution is again hashed and the number of leading zero bits (of that solution) determines the difficulty. I guess that is why zcashd reports solutions/s and not hashes/s since one solution is one try of a different nonce (and you need a lot of them to get lucky).
SHA256 and Blake2B cryptographic one-way hash functions are still used (I previously thought they weren't), but the speed of calculating them does not dominate mining speed anymore.

I found https://minezcash.com/zcash-mining-pool/ so apparently there are quite a few zcash mining pools already.
Regarding the difficulty question I am currently looking at https://github.com/str4d/zcash-pow/blob/master/pow.py What is irritating me is that there still is a SHA256 calculation apparently.


text:
I can't access my wallet at Bitknock cloud mining anymore
I was doing mining with Bitknock but they closed the website without informing us.
I can't access my wallet. Here is my wallet address
fnwg643zjnfwsqks

What must I do now? Should I acknowledge that I lost my Bitcoins?

Unfortunately, most of the "cloud mining" websites are ponzi schemes trying to disguise themselves as a cloud mining contract provider.
This site catagorizes Bitknock as a ponzi/scam dated back to November 2015. A little bit research could have made you aware of the dangers.
I personally lost dozens of bitcoin in such projects, even if I joined only the most secure looking. General rule of thumb: If it looks too good to be true, don't buy it.


text:
Bitcoind fails to start on Centos 7
When I execute bitcoind on CentOS 7 I get this error:
Unable to start HTTP server. See debug log for details.
 bitcoind: scheduler.cpp:19: CScheduler::~CScheduler(): Assertion `nThreadsServicingQueue == 0' failed.

There are a number of known issues on the compile side of things (under CentOS) which could be related: https://github.com/bitcoin/bitcoin/issues/6432.


text:
How to decode very huge (!) raw transactions?
I'm parsing the blockchain to extract certain information I need for a script.
One thing I do is parsing transactions. What I do is:
getrawtransaction <tx>
decoderawtransaction <rawtx>

This works on most of the transactions (>99%) but some are very huge and the bitcoin client cant handle them. I wonder what else can handle them if not bitcoind itself. The error I get in bitcoind:
TX decode failed (code -22)

Thats because it cant accept very long arguments. My ruby script dies with
Arguement list too long - (Errno::E2BIG)

How to decode such transactions? Here are some examples:
2f50fdf7adbf58e91d738869948f4b191eb3cafa016c6df7e9182c06e4513852
e7229316b5a5b1f53382ec5a526b842dda2ca96bc891cd02d397a52c4a84dba0
540359af779a510828f0afd3c88562b62c37d0e4eeccb08104a167a3600f7956

Thanks.

Update: I just tried to paste the rawtransaction to this online parser and this one decodes that transaction without any problems. How is that possible programmatically?

try this:
bitcoind getrawtransaction 2f50fdf7adbf58e91d738869948f4b191eb3cafa016c6df7e9182c06e4513852 1

note the 1 at the end, which instructs bitcoind to operate in verbose mode.

It sounds like you are passing the whole transaction on the command line, but your operating system has a limit on the maximum (combined) length of command line arguments, which has been exceeded. The message "Argument list too long" is an OS error, not from bitcoind itself.
You should be able to use the -stdin argument from bitcoin-cli to pass it via standard input instead of on the command line, in which case there are no length limits.  On a Unix-like operating system, you'll likely want to pass the data via a pipe, using popen(3) or its equivalent in your language of choice, but you could also write to a temporary file.

Bitcoind can accept very long inputs, but if you are using bitcoin-cli there is a limit on how long a command-line argument can be.  You can use the -stdin option to send the arguments to bitcoin-cli vis stdin and bypass the size limit on arguments.

There are libraries for deserializing transactions out there.
pybitcointools - python
bitwasp/bitcoin-php - php
libbitcoin - C++/C
OUTDATED: bitcoin-lib-php - php
There's bound to be many others.

Do you know of any in JavaScript? For example, can Bitcore deserialise transactions?


text:
Why is my p2pool share not payed out?
I'm mining Litecoins in the q30.qhor.net P2Pool node at a current rate of around 75 kH/s.
I've been reading that decentralized p2pool mining differs a bit from centralized mining pools, e.g. that you only get paid out when a block is solved successfully.
Now, I'm mining for about 8h now in this p2pool and during that time 3 blocks were solved:
Block   Time                            Luck
409925  Tue, 20 Aug 2013 17:09:16 GMT   155.4%
409848  Tue, 20 Aug 2013 14:02:12 GMT   95.1%
409784  Tue, 20 Aug 2013 12:07:41 GMT   165.1%

That means, some payouts occured during that time. I checked some of the other addresses, they really got instant payouts. But I didn't.
Address                             Hash Rate   Stale   Amount (LTC)
LV6GjHN8...someltcaddress..aWdKZ2g  2.93MH/s    4.36%   0.21685736
LWoKVQ8y...someltcaddress..2dm5FqL  2.44MH/s    5.12%   0.22766967
LedmP6yA...someltcaddress..hGBdLHW  1.97MH/s    7.02%   0.13804534
...
LUj1UAKL...myaddresshere...jWYAPA9  77.8kH/s    1.69%   -

I'm using pool's cpuminer 2.3.2 and see a lot of accepted shares.
 $ ./minerd --version
cpuminer 2.3.2
libcurl/7.31.0 OpenSSL/1.0.1c zlib/1.2.8
 $ ./minerd -a scrypt -r 1 -t 12 -s 6 -o http://q30.qhor.net:9327 -O LUj1UAKL...myaddresshere...jWYAPA9+0.00001800:1
...
[2013-08-20 20:57:05] thread 1: 168 hashes, 6.48 khash/s
[2013-08-20 20:57:05] accepted: 4270/4396 (97.13%), 76.76 khash/s (yay!!!)
[2013-08-20 20:57:05] thread 9: 4116 hashes, 6.41 khash/s
[2013-08-20 20:57:05] accepted: 4271/4397 (97.13%), 76.76 khash/s (yay!!!)
[2013-08-20 20:57:06] thread 2: 7452 hashes, 6.47 khash/s
[2013-08-20 20:57:06] accepted: 4272/4398 (97.14%), 76.76 khash/s (yay!!!)

But I did not get any payout, yet. Why?

The answer is hidden in this forum post here.

"You have the same problem that is common in P2Pool threads, your miner is (relatively) slow compared to the size of the pool, as such you are not solving the required 1 P2Pool share every 24 hours (not the work your miner is submitting). You will get paid when your miner solves a share with a difficulty greater than the current P2Pool Share difficulty (see the website), this is currently about 1.320658 (or 87.4k in CGMiner speak)."

The PPLNS payment system is not to be considered as the best for slow hash rate miners. To get payouts, you need to:

solve at least one hash every 24h hours which is higher than the p2pool share difficulty = gets at least one payout each day.
solve at least one hash within the window of the current block with a difficulty higher than the p2pool share difficulty = gets at least one payout each block.
check if your p2pool server avoids dust payments, meaning that very small payments are hold back until a certain threshold is reached, e.g. > 0.01 ŁTC.

I'm mining at around 100kH/s (867.9 block difficulty) and only recieving payments once every four/five blocks. This is a bit discouraging but in total I'm getting higher payouts than mining in normal pools.
By the way, the minimum recommended hashrate for p2pool-miners is 590 kHash/s.
Multiply by 65536 to convert to P2P difficulty to CGminer difficulty.

The p2pool payout method is based on PPLNS, so if your shares are not in the window of the blocks found, you will not get any payments.
I do not know if there is any other problem that could prevent you from receiving payment.
By the way, in centralized pools it is also true that you only get payment when a block is found, unless they are using PPS.

Not in the windows of the blocks? I'm mining now for around 30h, the pool found 15 Blocks in that time frame and I only got 4 payouts. (Mining LTC at ~100kH/s with two machines; scrypt.)


text:
Can't run Bitcoin Core 0.13.1
I have been running Bitcoin Core 0.12.1 for many months - using Ubuntu (Linux).  Decided to upgrade to SegWit version - 0.13.1 - today.  Downloaded and extracted the files (on my Ubuntu / Linux system) but can't get it to run - there is no executable file.  Can anyone help?  Many thanks, D

the ppa for ubuntu is https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin it shows the support of ubuntu 0.13.1
so you need to run
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update

otherwise you can compile from source

Many thanks - very grateful for the trouble you have gone to to reply.

Have done all that - still no bitcoin client (if that is what it is called) - i.e. no bitcoin core wallet appears

did you installed bitcoind and bitcoin-qt using sudo apt-get install bitcoin-qt? the gui wallet is runned using bitcoin-qt

That did the trick - many thanks - I really am most grateful for your help.  By the way, can you recommend a book on Linux terminal commands for a beginner like me?

I have accepted it - many thanks once again - you have been a great help.


text:
Is there a way to accept bitcoin payments and verify the identity of the people who paid without asking for any other information?
I have a website and I am considering supporting bitcoins, but I would like to do this without asking the users to log in nor give me their email or details before buying.
Is there a way to accept bitcoin payments and verify the identity of the people who paid without asking for any other information?
I would like the buyers to claim their product after they pay, using the transaction id, the confirmation number, the address... or something like this, so I do not have to ask for any other information before they buy, but I can be sure that I deliver the product to the right person.
That is, you can pay directly using my btc address (that will be different for each transaction) and you do not have to enter anything else.
After the transaction is confirmed, you can come back to the website and you can claim the product entering a "code". (Only then you'll be asked for the email or more details).
Can I use the pair of transaction addresses as this code? Is this secret or other people will be able to claim they paid?
Thank you very much!!

I suggest making the question in the second sentence the question in the title. It can better reflect the question for future searches. :-)

I made something exactly like what you need with sample code to be used with electrum bitcoin client. check it here. https://bitcointalk.org/index.php?topic=220494.0
I have been busy to develop it further but eventually I will get to it ^_^.
Enjoy and please share feedback.

You could have the customer send a message signed with the Bitcoin address used. This can be done with most Bitcoin clients or with most of the online wallets. This proves they have access to the private key for that address and are the owner.
Where they send the email from is not important as long as you can verify the message.
https://blockchain.info/wallet/features

Sign Message - Sign a message to prove you own a bitcoin adddress.

https://bitcoinarmory.com/start-page/what-is-armory/features/

Message signing with your Bitcoin addresses:   sign messages using the private keys of your bitcoin addresses, that can then be verified by someone else.  For instance, you pay someone 200 BTC for merchandise to be shipped to you.  You send the seller your postal address, but someone intercepts the message and replaces it with their own address!  This is avoidable by using signed messages:  the seller sees the money came from address X, so you send them a signature block, which tells them your postal address, and sign it with address X.  If someone tries to change the address, the signature will become invalid!

The best way is to generate a new bitcoin address for each order.  When the customer wants to check out, you display this address to the customer.  You also store this address in your database, associated with this particular order.  Once you see (by checking the blockchain) that the proper payment amount has been made to this address, and after waiting for however many confirmations you are comfortable with (usually 6) you should ship the product.
If you use an integrated payment system like bitpay, all this should be taken care of for you.

What number should they enter to be able to claim their product? The bitcoin address they have paid to?

Sorry I haven't understood your answer. Once I have received the payment, they will come back to the website to claim their product. How do we verify it's he/she who paid? Is it enough that they provide both addresses (sender, receiver)?

You collect all the information you need from them, display a new bitcoin address for them to pay. Once the payment goes through a few confirmations, either ship them the product (if physically shipping something) or send them a download link (if digitally shipping something). I don't see what the issue is or why they need to claim anything.

@aninom, does the customer login to your site?  If so, that's all they need to do to claim the product.  Once they login, you will be able to look up their unique pay-to address in your database, then check the blockchain that the address has been paid to (with enough confirmations).  If so, they can get their product.

Sorry for the confusion, they do not login to the site. I don't have any of their information. I want them to come back to claim the product and then give me the email. (I have changed the question so it is clearer)

aninom, can you have them give you the email before you give them the bitcoin address?  Then RentFree's above scheme will work.  It's equivalent to giving the email later because, no matter what, you're going to have to save a list of which bitcoin address or transaction id belongs to which customer.

@Eyal, asking for too much information upfront would just reduce the number of potential buyers...

If for some reason you don't want to create multiple bitcoin addresses*, you can use this arrangement:

Customer is given your single bitcoin address and a unique invoice number. The invoice number doesn't have to be secret just unique.
Customer is required to pay from a bitcoin address they have the private key for. Until they pay they don't have to tell anyone what this bitcoin address will be.
Once you have received and verified the payment, you record the bitcoin address it came from.
Customer picks up the purchase (or triggers physical delivery) by signing their invoice number with their private key. You verify the signature with their public key and send the delivery.
You can then delete the customer record from the database if you wish (and if legally permitted).

You should warn the customer that a purchase will not be delivered without a signed invoice number; and if automatic refunds occur for this service the refund will be to the address it came from - which may not be their specific logical wallet if they used an aggregate service provider or clearing house (the money becomes lost).
* Maybe to avoid transaction fees for aggregating payments, or you have a favorite wallet service, or you have a joint account with a company partner.

I can create multiple bitcoin addresses, no problem. I will use coinbase that does this automatically, but I don't want them to giveme any details upfront. I want them to come back and claim they paid once the product is ready. Can I do this? Can I ask them some number/id of the transaction and be sure that were them who paid? (I edited the question to make it clearer)

As I understood you are doing this without any login system, what you can do is generate a random alpha numeric code along with the address store this code with the address in database and prompt it to the customer. Also prompt a message that this is the unique identification number required to later claim their product. Rest process goes same like 6 confirmations etc.

I think I have an alternative that will work, since you are generating a unique address for each transaction.
When you generate the receiving address on your web server, also sign the address using the private key of the address; this generates a hash. You can present the address and the hash to your (potential) customer, letting them know that this hash is the code they will need to claim the product. The full hash is probably not necessary, you could get away with only presenting them with part of the hash (maybe the first 8-12 bytes).
Now the only person who knows the hash is your customer (assuming a secure web connection, no MITM, etc). It's not something that can be derived by anyone else based on what is in the blockchain since only you have the private key, and your customer can't do anything malicious with the hash.
You could do one of two things -- store the address and hash on your server (for easy lookup), or not (since there is no knowing whether they went through with a transaction or not, and you could end up with a database full of never-to-be-used hashes).
When the customer comes to claim their goods, they provide the address and the hash. Your server once again signs the address using the address's private key, and compares that hash against the claim code provided by the customer (or if you opted to store the addr/hash pairs you just do a lookup). If they match, you deliver their product.
I'm not sure if there are any gaps in this process; any feedback would be appreciated.

The benefit of this process over the other answers above is that it doesn't require the customer to know anything about signing messages with their Bitcoin client. It sounds like you are trying to make this as simple for the customer as possible.

I just also read that you are using Coinbase to generate the addresses; I originally thought you might have had a web server of your own that was generating addresses and could do the signing. I'm not sure how server-side signing would work with Coinbase, or if their APIs support it.


text:
Best practices for storing the bitcoin blockchain?
I have a few questions. One, is an SSD a good option to store the bitcoin blockchain. To unpack that question more, historically, has the blockchain size kept pace with Moore's law in relation to SSD technology?
Second, is a SAN drive array more appropriate to store bitcoin and other blockchains? I have done this before, it worked for my purpose as bitcoin is rather dynamic and slow compared to a typical database. The storage size is a clear upside. However, I wonder what is the impact with many big queries and also sync times?

I have done extensive tests without SDD, and later on with SSD. For sure downloading the bitcoin blockchain does not (!) require an SSD. However, everyone knows, it is faster using an SSD. There is heavy disk I/O, storing the blockchain, and there is also heavy CPU usage (re-) calculating the values, before they are stored on the local drive. One can give parameters to the bitcoin core client to increase memory usage (to speed up process), and you can for sure try to play with OS cache. So you need a fair amount of power to get along, and balance the parameters.
The bitcoin blocksize growth is pre-determined, so Moore's law is less relevant, and the blockchain growth is much, much less than Moore's law. Back to SAN: I had an older 1GB/sec attached SAN drive, with redundancy behind, and downloaded the blockchain on a 2 CPU machine. There was no problem, and it took only ~30% of my comparable desktop machine with an INTEL i7 processor (Unix OS).
Reliability of data is given through the SAN architecture, and the query speed is sufficient: you query the blockchain "sequentially", and for sure this is slow. Depends on your use case... But this is independant from the disk subsystem. However, the big "online explorers" (blockchain.info...) re-index the blockchain into the specific addresses, tx IDs and more, so that requests attain a satisfying speed.

Is this true though? https://www.reddit.com/r/btc/comments/6vgilz/question_bch_full_node_slow_sync/dm05b08/?st=jbp5az0e&sh=1d0d4fcb

I cannot judge, from my own experience: there are three areas to look at: network bandwidth (20 mbit should do), the network speed is not so relevant, cause when a block is transferred, the computer starts to decode the block and the tx inside. CPU power and RAM (a RASPI is certainly too slow, but a decent i7 is ok) and a SSD or storage system will bring you to the goal. If you have an older off-the-shelf SAN, with only 2 disks and 100mBit, then you'd go better for an SSD.

I might try an SSD. Though I question if it will help improve block sync times. For queries, maybe IOPS is important. I synced the testnet in a few days without much trouble. The main network is much slower. CPU, Mem, network, are all good. But I do have a small storage array linked with dual gigebit. I will post if I find something.

While moving the blockchain to an SSD, I noticed the SAN was using LAN instead of the network bond. That said, the SSD is noticeably faster at syncing blocks. I think there might be something to the IOPS story.


text:
Transaction fails to validate (Error running script)
I've created a transaction on the TESTNET and am trying to push it via BlockCyphers facility at:
https://live.blockcypher.com/btc-testnet/pushtx/
when I make the attempt, I get the following error:

Error validating transaction: Error running script for input 0
  referencing
  261190892daa2c9aaaf25c20624f7f2941d2ad58dec883b0c929d1fa9306fd57 at 0:
  Script was NOT verified successfully..

here's the transaction.  I don't see what the matter with it is and not sure I understand the error.  can anyone help?
{
    "addresses": [
        "mjGtZWXgPdbLUZYWtDqVTfbFieVzXFfSEj",
        "2N7nSZjfqikj4oVkCqaLB3CNMY3TA72PbNY",
        "msp7depXvcjLqykZxYVrWNG9QgKqLWWKEN"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 12375,
    "hash": "463372d7a8f456c882179635aabbeca4146396b1f81c05699a2e885e3f84d6e6",
    "inputs": [
        {
            "addresses": [
                "mjGtZWXgPdbLUZYWtDqVTfbFieVzXFfSEj"
            ],
            "age": 1657999,
            "output_index": 0,
            "output_value": 5000000,
            "prev_hash": "261190892daa2c9aaaf25c20624f7f2941d2ad58dec883b0c929d1fa9306fd57",
            "script": "48304502210093b8ff9180a8a31a5ee7b0fb6c560aef888a3d53576e530cb4601dce2d3c51da02204fd8a28743f1d1100a2f56428e743501091e833550df6cf540bad4f5248a6d3c012102d794c7e1a8068782ef6ee68acf9f6ad9c84c78349671c1a7bf60418a8e1ed108",
            "script_type": "pay-to-pubkey-hash",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "2N7nSZjfqikj4oVkCqaLB3CNMY3TA72PbNY"
            ],
            "script": "a9149f792783320ffb5a4f3ee4c69525d4932ac0497087",
            "script_type": "pay-to-script-hash",
            "value": 500
        },
        {
            "addresses": [
                "msp7depXvcjLqykZxYVrWNG9QgKqLWWKEN"
            ],
            "script": "76a91486e0602ab38efd1811ff4db76f7d58c717c8598888ac",
            "script_type": "pay-to-pubkey-hash",
            "value": 4987125
        }
    ],
    "preference": "high",
    "received": "2020-01-10T05:09:49.945289619Z",
    "relayed_by": "54.197.194.161",
    "size": 224,
    "total": 4987625,
    "ver": 2,
    "vin_sz": 1,
    "vout_sz": 2
}

- Addendum I -
to help narrow down the solution, here's the code I'm using to produce the transaction:
I first produce an address where to receive some coin:
const btc = require('bitcoinjs-lib');
const bip39 = require('bip39');
const bip32 = require('bip32');

var mnem = 'my-12-word-bip39-seed-phrase'
var root = = bip32.fromSeed(
  bip39.mnemonicToSeedSync(mnem), bitcoin.networks.testnet
);
var p = "m/44'/1'/0'/0/0"
var pubkey = root.derivePath(p).publicKey;
var {address} = btc.payments.p2pkh({pubkey, network: btc.networks.testnet});
console.log(address);

which yields mjGtZWXgPdbLUZYWtDqVTfbFieVzXFfSEj.  I then send some coin to that address and attempt to create my transaction:
const CS = require('coinselect');
var feeRate = 55;
var env = 'test3'
var src = 'mjGtZWXgPdbLUZYWtDqVTfbFieVzXFfSEj'
var url = `https://api.blockcypher.com/v1/btc/${env}/addrs/${src}?unspendOnly=true`;
var o = await fetch(url).then(res => res.json());
var utxos = o.txrefs.map(o => ({
    txId: o.tx_hash,
    vout: parseInt(o.tx_output_n),
    value: parseInt(o.value)
}));
var targets = [{address: '2N7nSZjfqikj4oVkCqaLB3CNMY3TA72PbNY', value: 500}];
var {inputs, outputs, fee} = CS(utxos, targets, feeRate);
if (ret.outputs) ret.outputs.forEach(o => {
    if (!o.address) o.address = 'msp7depXvcjLqykZxYVrWNG9QgKqLWWKEN';
})

// builds the transaction
var tx = new btc.TransactionBuilder(btc.networks.testnet);
inputs.forEach(o => tx.addInput(o.txId, o.vout));
outputs.forEach(o => tx.addOutput(o.address, o.value));
tx.sign(0, root);
console.log(tx.build().toHex());

from which I get a numerical string that converts to the above transaction.  as can be seen, I'm using the same root to sign the transaction that was used to create the source address

Can you show or tell us how you are creating your transaction? Hard to say without more info.

yes.  I will post code to help identify the issue

You have the wrong public key inside your SignatureScript:
Sig: 48-304502210093b8ff9180a8a31a5ee7b0fb6c560aef888a3d53576e530cb4601dce2d3c51da02204fd8a28743f1d1100a2f56428e743501091e833550df6cf540bad4f5248a6d3c-01
pubkey: 21-02d794c7e1a8068782ef6ee68acf9f6ad9c84c78349671c1a7bf60418a8e1ed108

The outpoint you are spending (2611[...]fd57:0) has the following PubkeyScript:
76-a9-14-2937902660c169b9381a5b3eb35cc889a4686a85-88-ac

When the script runs it fails on 0x88 (or OP_EqualVerify) because HASH160 of the given public key (02d7[...]d108) is e652ed9163ac72629584ec92f47602cca45aa969

amazing feedback.  I will try to follow your logic and figure it out.  thanks a million

I've added code to the post to clarify how I'm building the transaction and what I'm using to sign

ok.  I've come to understand what you said, and I gather that the field inputs[0].script is populated by my call to the transaction builder's sign() function.  that doesn't match the script-pubkey that Block.io generated when I sent coins from there to my address mjGtZWXgPdbLUZYWtDqVTfbFieVzXFfSEj... so the question is why that would happen (and how to fix it)

FWIW, if I console.log(pubkey.toString('hex') I get:  026c4df6ad30a627bcb045faf913bb25aad26ef9d06a838f8465aead0a63c869ad... which seems to be the Hash160 of 15iBr8YmiWhXbCWRtZhuY9zowF412EwCypjNvY3xX79CX12K8ZH

as you can see, I'm passing the root directly to the signature function.  originally I was converting to a WIF and then to a key, but I was told I could pass the root directly.  see: https://github.com/bitcoinjs/bip39/issues/129#issuecomment-572365691

I'm not familiar with bitcoinjs library you have to check the source code/read its docs. But it seems to me that you are passing the "root key" in both your tries. To sign a transaction you need the same "child" key that was used to create the address not the root.

yes.  you're correct.  it took me a while to figure out how to fix it but you gave me all I needed.  I owe you a beer


text:
What is a bitcoin wallet?
I do not understand how addresses and wallets are related. I see that you are advised to generate an address for every transaction and, furthermore, use (multi-in multi-out) tumblers to maintain anonimity. This will create a hell amount of (unspent) keys+addresses. How do you manage them all and handle complexity? How do you remember that this was a simple transaction from that wallet to mine and the rest is just intermediate activity. Is a wallet just a collection of (unspent) addresses so that you can simply merge different (wallets of) bitcoins by just gathering these keys/addresses? I understand that to have a coin means that you know which address has some unspent bitcoins and you have a key to demonstrate that it is your coin/address in the next transaction. But what if you share same coin addresses between wallets and one wallet will think that there are still money while you spent them (peahaps partially)? What about compatibility of various wallets, is there a strandard/converter? Am I right that the thing that you must keep in mind is the list of addresses plus corresponding keys and the wallet is such a record?

related: Wallets vs Addresses, What's the difference between a wallet an an address?

Please focus on one question per post. Your array of topics turns out to be a composite of duplicates to about half a dozen questions already answered on this site. Additionally to the above those include: What information does a wallet contain?, Can wallets be shared by different machines?, Is it safe to reuse a Bitcoin address?

You are asking a lot of questions in one post but to answer the question in your title concisely:

A Bitcoin wallet is loosely the equivalent of a physical wallet on the
Bitcoin network. The wallet actually contains your private key(s)
which allow you to spend the bitcoins allocated to it in the block
chain. Each Bitcoin wallet can show you the total balance of all
bitcoins it controls and lets you pay a specific amount to a specific
person, just like a real wallet. This is different to credit cards
where you are charged by the merchant.

From Bitcoin.org.
A wallet contains any number of public/private keys.  You can easily create new wallets or new public/private keys in your existing wallet.
I'd recommend breaking down anything still unanswered into their own specific question.

It will be classified as double-spending and won't suceed
Quoted from https://en.bitcoin.it/wiki/Double-spending :

...Bitcoin protects against double spending by verifying each
  transaction added to the block chain to ensure that the inputs for the
  transaction had not previously already been spent.

===============================================================================
Take the keys and addresses as a bank card, I'd say. Each bank card has it's code, so as Bitcoin.
Those keys are somewhat localized(thus a private key is needed for wallet transferring)
blockchains only works as a transaction recording platform.
===============================================================================
Bitcoin is using Secp256k1
===============================================================================
"Such a record" is needed as this identifies you on network. A good way is keep it on a paper and lock into a safe.
===============================================================================
More info: Private key

Ok, what is a wallet? Do you keep the private key of your wallet? Do you see that I point out that you need a new address for every transaction? Why do I ask that? Are you saying that it is ok that a new paper added into your wallet with every transaction?

A wallet is just a thing for you to store your bitcoins. You should keep your private key or you will lose access to your wallet(quite obvious). No, you don't. You can generate as many address as you like and paper record it then label it like "My Wallet", "Other Transactions" etc. or you can just do 1 key and have it in your mind or in a paper, too. Thus the next question and the last question is invalid.


text:
Bitcoin transaction stuck as unconfirmed with no fee
I could have sworn when i tried withdrawing BTC to my local BTC wallet i set the fee to 0.005
The blockchain shows no fee was paid and the transaction is hanging with 0 confirmations.
I really am trying to get this BTC ASAP.
Any ideas? Here is the transaction link.
https://blockchain.info/tx/0b30583b830a7ee674dd92f0a22b3d4b21c81b5f80687b2ad2e6b951a64ef4e2
Also: the transaction seems to be moving BACK in the queue

Looks like it has 40 confirms now.otherwise you could basically do a double spend of those coins and send the transaction with a fee. The transaction with the highest fees would get integrated more rapidly. From there the transaction with the lower fee would bounce be negated.

you need to create a raw transaction. Brain wallet has a nice utility to do so(but never use that address again afterwords) http://brainwallet.org/#tx . This is a handy tool to broadcast a raw transaction once you generate it as well.

@JoeWhite, But the bitcoin client wouldn't allow you to double-spend the coins right? I have a situation like his, are the coins stuck then?

I'm voting to close this question as off-topic because it's already resolved itself.


text:
Recovering private key when someone uses the same k twice in ECDSA signatures
In this blog: https://web.archive.org/web/20160308014317/http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
the author showed a case that using same k twice will leak private key.
Many people know this method. But I find sometimes, the formula can not give the right answer(or I compute wrong).
Look at this, you can verify signatures by public key:
public_key = 02a50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364
msghash1 = 01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6
msghash2 = 339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1
sig1 = 304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02206cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
sig2 = 304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02204ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2

So input data:
r=0861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d
s1=6cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
s2=4ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2
z1=01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6
z2=339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1

I work out:
private key = eaa57720a5b012351d42b2d9ed6409af2b7cff11d2b8631684c1c97f49685fbb
public key = 04e0e81185567ea58fc7e7258aa4d5c3e201a8d4ce2810c1007d87727a67eeb9a8c2ba06935280209f8bf42fc7603b65095f036044c4124ddf7c6a250cb450e4c8

However, it's wrong.
I'm using this python code to compute:
# this function is from
# https://github.com/warner/python-ecdsa/blob/master/ecdsa/numbertheory.py
def inverse_mod( a, m ):
    """Inverse of a mod m."""
    if a < 0 or m <= a: a = a % m
    # From Ferguson and Schneier, roughly:
    c, d = a, m
    uc, vc, ud, vd = 1, 0, 0, 1
    while c != 0:
        q, c, d = divmod( d, c ) + ( c, )
        uc, vc, ud, vd = ud - q*uc, vd - q*vc, uc, vc

    # At this point, d is the GCD, and ud*a+vd*m = d.
    # If d == 1, this means that ud is a inverse.
    assert d == 1
    if ud > 0: return ud
    else: return ud + m

def derivate_privkey(p, r, s1, s2, hash1, hash2):
    z = hash1 - hash2
    s = s1 - s2
    r_inv = inverse_mod(r, p)
    s_inv = inverse_mod(s, p)
    k = (z * s_inv) % p
    d = (r_inv * (s1 * k - hash1)) % p
    return d, k

p  = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

# this case is right
public_key=0x04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff
r =0xd47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1
s1=0x44e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e
s2=0x9a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab
z1=0xc0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e
z2=0x17b0f41c8c337ac1e18c98759e83a8cccbc368dd9d89e5f03cb633c265fd0ddc
print "private:%x\n random:%x" % derivate_privkey(p,r,s1,s2,z1,z2)
print

# this case can be wrong
public_key=0x02a50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364
r =0x0861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d
s1=0x6cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
s2=0x4ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2
z1=0x01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6
z2=0x339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1

print "private:%x\n random:%x" % derivate_privkey(p,r,s1,s2,z1,z2)

In fact, there have another one met this problem:
https://crypto.stackexchange.com/questions/16615/ecdsa-how-to-retrieve-a-non-random-k
But he didn't gave more infomation, maybe he figured it out.
I have not found more people complaining about it, so, it's likely my fault somehow.
Can you point out my error? or just point out the right way? Thank you.

It seems like the second public key is compressed - maybe that's the issue?

no, signature has nothing to do with public key compressed or not. because verifing signature always using uncompressed public key. and the formula doesn't need public key.

Here is a fun thing about ECDSA signatures: you can always replace s with -s (mod N) and the signature is still valid.  So when you are deducing the k value, it is possible that someone else flipped the sign of s and you will have to undo it.  So, you have to make a list of candidates for k (kandidates?) and then select whichever one actually works.  A good list of k candidates would be:

(z1 - z2) / (s1 - s2)
(z1 - z2) / (s1 + s2)
(z1 - z2) / (-s1 - s2)
(z1 - z2) / (-s1 + s2)

I like to use the Ruby ECDSA gem to play around with this kind of stuff.  Here is the code I wrote which successfully finds the private key for the first input data you gave:
require 'ecdsa'

public_key_hex = '02a50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364'
msghash1_hex = '01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6'
msghash2_hex = '339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1'
sig1_hex = '304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02206cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188'
sig2_hex = '304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02204ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2'

group = ECDSA::Group::Secp256k1

def hex_to_binary(str)
  str.scan(/../).map(&:hex).pack('C*')
end

public_key_str = hex_to_binary(public_key_hex)
public_key = ECDSA::Format::PointOctetString.decode(public_key_str, group)

puts 'public key x: %#x' % public_key.x
puts 'public key y: %#x' % public_key.y

msghash1 = hex_to_binary(msghash1_hex)
msghash2 = hex_to_binary(msghash2_hex)
sig1 = ECDSA::Format::SignatureDerString.decode(hex_to_binary(sig1_hex))
sig2 = ECDSA::Format::SignatureDerString.decode(hex_to_binary(sig2_hex))

raise 'R values are not the same' if sig1.r != sig2.r

r = sig1.r
puts 'sig r: %#x' % r
puts 'sig1 s: %#x' % sig1.s
puts 'sig2 s: %#x' % sig2.s

sig1_valid = ECDSA.valid_signature?(public_key, msghash1, sig1)
sig2_valid = ECDSA.valid_signature?(public_key, msghash2, sig2)
puts "sig1 valid: #{sig1_valid}"
puts "sig2 valid: #{sig2_valid}"

# Step 1: k = (z1 - z2)/(s1 - s2)
field = ECDSA::PrimeField.new(group.order)
z1 = ECDSA::Format::IntegerOctetString.decode(msghash1)
z2 = ECDSA::Format::IntegerOctetString.decode(msghash2)

k_candidates = [
  field.mod((z1 - z2) * field.inverse(sig1.s - sig2.s)),
  field.mod((z1 - z2) * field.inverse(sig1.s + sig2.s)),
  field.mod((z1 - z2) * field.inverse(-sig1.s - sig2.s)),
  field.mod((z1 - z2) * field.inverse(-sig1.s + sig2.s)),
]

private_key = nil
k_candidates.each do |k|
  next unless group.new_point(k).x == r
  private_key_maybe = field.mod(field.mod(sig1.s * k - z1) * field.inverse(r))
  if public_key == group.new_point(private_key_maybe)
    private_key = private_key_maybe
  end
end

puts 'private key: %#x' % private_key

The output of the program is:
public key x: 0xa50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364
public key y: 0x7954da3444d33b8d1f90a0d7168b2f158a2c96db46733286619fccaafbaca6bc
sig r: 0x861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d
sig1 s: 0x6cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
sig2 s: 0x4ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2
sig1 valid: true
sig2 valid: true
private key: 0xe773cf35fce567d0622203c28f67478a3361bae7e6eb4366b50e1d27eb1ed82e

very good! I find the first two candidates are enough, last two are the same thing.

I considered that, but actually you do need all 4 candidates.  Only one of the 4 produces the right public key in the end.  The formula (s*k-z)/r is affected by the sign of k.

Adding to David Grayson's excellent answer the python ecdsa-private-key-recovery library is an easy to use wrapper for ecdsa/dsa signatures that is capable of recovering the private key from signatures sharing the same k/r. Once recovered you'll get ready to use private key populated Cryptodome/PyCrypto/ecdsa objects. The lib can easily be used to recover private keys from vulnerable btc transactions.

r =0x0861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d
s1=0x6cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
s2=0x4ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2
z1=0x01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6
z2=0x339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1

h1 = r*(s1-s2)
p1 = (z1*s2) - (z2*s1)

h1 = r*(s1+s2)
p1 = (z1*s2) - (z2*s1)

h1 = r*(-s1-s2)
p1 = (z1*s2) - (z2*s1)

h1 = r*(-s1+s2)
p1 = (z1*s2) - (z2*s1)

h1 = r*(s1-s2)
p1 = (z1*s2) + (z2*s1)

h1 = r*(s1+s2)
p1 = (z1*s2) + (z2*s1)

h1 = r*(-s1+s2)
p1 = (z1*s2) + (z2*s1)

h1 = r*(-s1-s2)
p1 = (z1*s2) + (z2*s1)
print(hex((p1 *inverse_mod(h1, p)) % p))

output:
0xe773cf35fce567d0622203c28f67478a3361bae7e6eb4366b50e1d27eb1ed82e

Based on OP's existing formula and David Grayson's answer above, here is a more modern (Python 3.8+) solution that works for both Bitcoin and Ethereum accounts, for those curious:
r = 0x...
s1 = 0x...
s2 = 0x...
# For Ethereum msg hash, feel free to use this excellent online toolkit: https://toolkit.abdk.consulting/ethereum#recover-address
z1 = 0x...
z2 = 0x...

# This function is from
# https://github.com/tlsfuzzer/python-ecdsa/blob/master/src/ecdsa/numbertheory.py
def inverse_mod(a, m):
    """Inverse of a mod m."""
    if a == 0:  # pragma: no branch
        return 0
    return pow(a, -1, m)

# Magic: https://en.bitcoin.it/wiki/Secp256k1
p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

for (i, j) in [(1,1),(1,-1),(-1,1),(-1,-1)]:
    z = z1 - z2
    s = s1*i + s2*j
    r_inv = inverse_mod(r, p)
    s_inv = inverse_mod(s, p)
    k = (z * s_inv) % p
    d = (r_inv * (s1 * k - z1)) % p
    print(f"Private key: {hex(d)}, {hex(k)}")


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

FYI: I haven't followed the details on this BIP, but an earlier name for (I think) a similar proposal was "Stealth Address".

The gist of the reusable payment code BIP is that you can gain some measure of address privacy by combining BIP32 (hierarchical deterministic wallets) with Diffie-Hellman key exchange. To understand what this means, let's figure out what the current situation of bitcoin wallets is.
Originally, in the reference client, bitcoin wallets simply generated random numbers for private keys, which in turn created a bunch of random addresses. This worked great for sending and receiving, but for privacy, it's not so great. If you publish your address, for example, everyone knows exactly how much you're receiving to that address since the blockchain is a public ledger.
Next came along Deterministic Wallets from Armory. This allowed a single seed to generate a virtually infinite number of addresses. That is, you can generate a single wallet from 256 bits (or less) and get as many addresses as you need. This allowed people to send Armory watch-only wallets to each other and get paid that way. Much better for privacy since you're generally only supposed to use new addresses, but once someone is in possession of your watch-only wallet, they know all the transactions in and out of that wallet. Better than it being public, of course, but still something to be desired when it comes to financial privacy, if, say, your employer was paying you via an Armory watch-only wallet, they know exactly how much of that has been moved and so on.
Then came HD wallets (hierarchical deterministic wallets) which allow you to have multiple levels of wallets from a single seed. Now you can send one person one watch-only wallet (xpub in BIP32 parlance) and another person another watch-only wallet and they won't know anything about what the other one is doing. Again, better for privacy, but now you have to give out different watch-only wallets to everyone you're dealing with, which can get messy.
Reusable Payment Codes is essentially a single code (essentially an xpub from BIP32) that you can publish that creates a new wallet when combined with any other HD wallet. This works via Diffie-Hellman key exchange where the sender uses the xprv from their HD Wallet and combine that with the receiver's xpub to come up with essentially a wallet that only the receiver can open but both the sender and receiver can determine the addresses of. As part of the key exchange, the sender has to send the receiver their xpub so the payments can be bi-directional. If you need a refund, for instance, the Payment Code is symmetric so a wallet going the other way can be deterministically be known to both sides. A refund can be sent to the payment code without crazy work-arounds that typify the current bitcoin landscape.
Reusable Payment Codes are essentially a way to identify yourself without leaking any information about how much was received by or sent to that payment code. Addresses, deterministic wallets and HD wallets all do not have this ability.

Great answer, thanks Jimmy! I asked a similar question recently, perhaps you can weigh in on this?

This is a good explanation in general, but the paragraph about the reusable payment codes is a bit vague. If the receiver can determine the address, how come he cannot "watch" that address? Does the payment code being bidrectional mean the same code can be used for payments from A to B and from B to A?

The sender and receiver both know the combined wallet, but they don't know about any other wallets. This is nice from a privacy perspective. And yes, the payment code being bidirectional means that if A know's B's payment code, B must know A's payment code so two different wallets can be made one that sends from A to B and another that sends from B to A. BTW, if you want a more thorough answer, please ask a StackeExchange question so I have more room to elaborate =)


text:
Non standard Tx with obscure OP codes: examples
I've been writing Python code to fetch various transactions and came across this: 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69.
The script field is as follows:

scriptPubKey: "OP_IF OP_INVALIDOPCODE 4effffffff ........... OP_ENDIF" (where ..... is the hex data, all ~2900 bytes worth)

What is going on with..?:

OP_IF / OP_ENDIF codes (wiki says they correctly open and finish a script)
OP_INVALIDOPCODE
0x4effffffff
the HUGE data size of
46726f6d2061336136316665663433333039623966623233323235646637393130623033616663353436356239204d6f6e205365702031372030303a30303a303020323030310a46726f6d3a205361746f736869204e616b616d6f746f203c7361746f7368696e40676d782e636f6d3e0a446174653a204d6f6e2c2031322041756720323031332030323a32383a3032202d303230300a5375626a6563743a205b50415443485d2052656d6f7665202853494e474c457c444f55424c4529425954450a0a492072656d6f76656420746869732066726f6d20426974636f696e20696e20663165316662346264656638373863386663313536346661343138643434653735343161376538330a696e2053657074203720323031302c20616c6d6f73742074687265652079656172732061676f2e204265207761726e6564207468617420492068617665206e6f740a61637475616c6c792074657374656420746869732070617463682e0a2d2d2d0a206261636b656e64732f626974636f696e642f646573657269616c697a652e7079207c2020202038202b2d2d2d2d2d2d2d0a20312066696c65206368616e6765642c203120696e73657274696f6e282b292c20372064656c6574696f6e73282d290a0a64696666202d2d67697420612f6261636b656e64732f626974636f696e642f646573657269616c697a652e707920622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a696e64657820363632303538332e2e38396239623162203130303634340a2d2d2d20612f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a2b2b2b20622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a4040202d3238302c3130202b3238302c38204040206f70636f646573203d20456e756d65726174696f6e28224f70636f646573222c205b0a2020202020224f505f57495448494e222c20224f505f524950454d44313630222c20224f505f53484131222c20224f505f534841323536222c20224f505f48415348313630222c0a2020202020224f505f48415348323536222c20224f505f434f4445534550415241544f52222c20224f505f434845434b534947222c20224f505f434845434b534947564552494659222c20224f505f434845434b4d554c5449534947222c0a2020202020224f505f434845434b4d554c5449534947564552494659222c0a2d2020202028224f505f53494e474c45425954455f454e44222c2030784630292c0a2d2020202028224f505f444f55424c45425954455f424547494e222c20307846303030292c0a2020202020224f505f5055424b4559222c20224f505f5055424b455948415348222c0a2d2020202028224f505f494e56414c49444f50434f4445222c20307846464646292c0a2b2020202028224f505f494e56414c49444f50434f4445222c2030784646292c0a205d290a200a200a4040202d3239332c3130202b3239312c3620404020646566207363726970745f4765744f70286279746573293a0a202020202020202020766368203d204e6f6e650a2020202020202020206f70636f6465203d206f72642862797465735b695d290a20202020202020202069202b3d20310a2d20202020202020206966206f70636f6465203e3d206f70636f6465732e4f505f53494e474c45425954455f454e4420616e642069203c206c656e286279746573293a0a2d2020202020202020202020206f70636f6465203c3c3d20380a2d2020202020202020202020206f70636f6465207c3d206f72642862797465735b695d290a2d20202020202020202020202069202b3d20310a200a2020202020202020206966206f70636f6465203c3d206f70636f6465732e4f505f5055534844415441343a0a202020202020202020202020206e53697a65203d206f70636f64650a2d2d200a312e372e392e340a0a `

Which decodes to:
c ♣N    Mú♣From a3a61fef43309b9fb23225df7910b03afc5465b9 Mon Sep 17 00:00:00 2001
From: Satoshi Nakamoto <satoshin@gmx.com>
Date: Mon, 12 Aug 2013 02:28:02 -0200
Subject: [PATCH] Remove (SINGLE|DOUBLE)BYTE

I removed this from Bitcoin in f1e1fb4bdef878c8fc1564fa418d44e7541a7e83
in Sept 7 2010, almost three years ago. Be warned that I have not
actually tested this patch.
---
 backends/bitcoind/deserialize.py |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/backends/bitcoind/deserialize.py b/backends/bitcoind/deserialize.py
index 6620583..89b9b1b 100644
--- a/backends/bitcoind/deserialize.py
+++ b/backends/bitcoind/deserialize.py
@@ -280,10 +280,8 @@ opcodes = Enumeration("Opcodes", [
     "OP_WITHIN", "OP_RIPEMD160", "OP_SHA1", "OP_SHA256", "OP_HASH160",
     "OP_HASH256", "OP_CODESEPARATOR", "OP_CHECKSIG", "OP_CHECKSIGVERIFY", "OP_CHECKMULTISIG",
     "OP_CHECKMULTISIGVERIFY",
-    ("OP_SINGLEBYTE_END", 0xF0),
-    ("OP_DOUBLEBYTE_BEGIN", 0xF000),
     "OP_PUBKEY", "OP_PUBKEYHASH",
-    ("OP_INVALIDOPCODE", 0xFFFF),
+    ("OP_INVALIDOPCODE", 0xFF),
 ])

@@ -293,10 +291,6 @@ def script_GetOp(bytes):
         vch = None
         opcode = ord(bytes[i])
         i += 1
-        if opcode >= opcodes.OP_SINGLEBYTE_END and i < len(bytes):
-            opcode <<= 8
-            opcode |= ord(bytes[i])
-            i += 1

         if opcode <= opcodes.OP_PUSHDATA4:
             nSize = opcode
--
1.7.9.4

h

Are there other non-standard transaction examples which are similarly noteworthy? To be clear, the hidden code is fun, but I'm looking for non-standard usage of OP_CODEs in Txns which have preferably been accepted as well formatted.

There has been discussion about this particular transaction before on reddit. This is clearly not a valid transaction and was probably used to store data on the blockchain before OP_RETURN.
Why was it relayed? It may not have been. There's a very easy way to get a transaction like this included and it's by submitting the transaction directly to a mining pool like eligius. As long as you add a high enough fee, they will process valid, but non-standard transactions.

I've edited my original post to reframe the question's scope, namely, what are some other non-standard transactions (i.e. not 76a914__88ac or multisig related) (fantastic answer btw)

I found an INCREDIBLY detailed spreadsheet documenting every single "weird" Tx up until March 2014. It's available at John Ratcliff's Code Suppository in his "Transaction Input Signatures in the Bitcoin Blockchain over time" blog post, which in itself, is an incredibly comprehensive source of technically based Bitcoin information.

Spreadsheet documenting "weird Txns" (March 4th, 2014 link)

Similar in discussion and conclusions, Ken Shirriff assesses Txn Malleability in his discussion, which is especially noteworthy since both these articles date from around the Mt. Gox implosion of Feb. 2014.
From John Ratcliff:

On November 26, 2013 a whole bunch of input scripts show up which
  appear to all be considered valid by blockchain.info but when I
  processed them I found that they still had extra data on the stack
  after the signature portion had been parsed.  This doesn't make them
  invalid, just unusual.

He continues:

On seven occasions, instead of finding the expected SIGHASH_ALL byte
  of 0x01 a SIGHASH byte of 0 was found instead.  For those transactions
  blockchain.info appears to mark them as valid, though I'm not sure why
  it is.
On 120 occasions, the SIGHASH_ALL value is found, however, it is
  preceded by a single zero byte.
An additional 45 times prior to encountering SIGHASH_ALL multiple zero
  bytes are found.
On one occasion in the blockchain, prior to finding the SIGHASH_ALL
  value there was a stream of 0x2A bytes.  Blockchain.info still flagged
  this as being a valid transaction, so I guess this is acceptable,
  though I'm not sure why.
Eleven times I found a public key signature that was just hex 0x21
  bytes long instead of the standard 0x41 value we are used to seeing.
Several thousand transactions use the PUSHDATA0 instruction in the
  front of the script, and then I couldn't fully parse all of the
  signature.  There is probably nothing wrong with this format, it's
  just not the most standard and I haven't taken it into account yet.
SIGHASH_PAY_ANY and SIGHASH_PAY_SINGLE were used like a hundred times
  or so.

Examples provided include:

the first transaction in the blockchain which has an 'abnormal' signature (block #157785, DEC 17, 2010)
On December 13, 2013, the blockchain got spammed with a huge number of inputs which have invalid script signatures.
The next abnormal input happens on January 7, 2013, with an input script that just contains OP_1 (a true statement).  This happens again on January 20, 2013.
On July 21, 2013 someone left an amusing text message in their signed transaction.  Blockchain.info identifies this signed transaction as being of 'Escrow' type.

Some other amusing Txns to note:

38df010716e13254fb5fc16065c1cf62ee2aeaed2fad79973f8a76ba91da36da: I should not run the washing machine while listening to WZBC. I managed to convince myself that the machine was slowly failing -- that a rythmic, squeaking noise it had been making had gotten a little worse. Ten minutes later, though, the machine had paused. But the noise was still there.
320a5c8eb5e8e0d4fc2ae48fc6f2d1c86ebe637193a61fcc9a13925d9cf96b1b: All your dummy values are belong to us.

And....in this Tx's scriptSig, a meta-joke of sorts, referencing Terminator's Skynet AI!:

61e26d407c17e8ee33a8b166c78f78c53cdcdc0078ae1f9405e6583cfb90eaf4:

Skynet went online on August 4th 1997, and began to learn at a geometric rate. It became self-aware on August 29th 1997 2:14 am
  Eastern Time. On August 29th 1997 2:15 am it discovered nihilism, and
  either shut itself down due to despair, or because it was logical.
  We're not sure which.
On August 4th, 1998, it failed to renew its domain name, which was promptly squatted on by a link farmer pitching X10 cameras and singing
  electric fish.

March 2015 edit:
A Survey of Bitcoin Transaction Types from QuantaBytes provides another great source of various Tx and historical commentary (ie first instance of a P2SH Tx =  9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6)


text:
Ramifications of creating Electrum 2.x seeds which are not BIP39
Electrum 2.0 seeds (mnemonic phrases) are created with a checksum based algorithm (such that the hmac_sha512 starts with 01. It's usually a 13 word seed, but can be 12 in some circumstances.
If all 12 word Electrum 2.x seeds were filtered such that they are not BIP39 compatible, what is the decrease in entropy going to be?
=> The question pertains to this Python code
I guess the problem can be summed up as:

What is the percentage of 12 words Electrum 2.x seeds (relative to 13 word seeds)?
What is the percentage of Electrum 2.x (12 word) seeds which do not meet the BIP39 standard? (The last word decides the checksum)

For the purposes of this answer, I'll assume we're only talking about mnemonics which can be generated by Electrum 2.x, and not ones that are simply accepted by Electrum 2.x for restore (the latter number is infinite).

What is the percentage of 12 words Electrum 2.x seeds (relative to 13 word seeds)?

Electrum 2.x seeds by default encode 136 bits of data. Any leading zero bits are ignored during encoding, so the resulting mnemonic length varies.
Each word encodes log2(word_list_length) bits of data, so for most* Electrum 2.x word lists, that's log2(2048) = 11 bits per word.
Therefore 13 and 12-word long mnemonics can encode up to 143 and 132 bits of data respectively. In order for a 136-bit seed to be encoded into 132 bits (12 words), at least the first 4 bits must be zero, which happens with probability 1 in 24, so 1 in 16 random mnemonics will be of length 12 or fewer.
Likewise, for an 11-word mnemonic, encoding 136 bits into 121 bits requires that 15 leading bits must be zero, so 1 in 215 or 1 in 32768 will be of length 11 or fewer.
Finally, if you need an exact answer, it would be 1/16 - 1/32768 = 2048/32768 - 1/32768 = 2047 in 32768 will be of length 12 exactly.
* For the Portuguese word list, it's log2(1626) ≈ 10.67 bits per word

What is the percentage of Electrum 2.x (12 word) seeds which do not meet the BIP39 standard?

12-word long BIP-39 mnemonics have 4 bits of checksum, so 1 in 24 generated 12-word Electrum 2.x mnemonics will happen to be valid BIP-39 ones, and 15 in 16 Electrum ones will be invalid for BIP-39.

If all 12 word Electrum 2.x seeds were filtered such that they are not BIP39 compatible, what is the decrease in entropy going to be?

I'm interpreting this as asking: If valid Electrum 2.x mnemonics were required to be invalid BIP-39 ones, by how much would this decrease their entropy?
Wolfram|Alpha says very small: about 0.0056 bits based on this input:
solve  (2^n - 1) / 2^n = 2047/32768 × 1/16  for n

Wow! Fantastic work! I'll see what @ThomasV thinks of this for differentiating BIP39 and Electrum 2.x: seems a good consideration. Also, I did notice Portuguese strays back to Electrum 1.x word list size myself and wondered, what on earth is going on?

@WizardOfOzzie Thanks! IIUC, Monero Core borrowed Electrum 1.x's seed generation method and original English word list, and then added new word lists all of the same size as Electrum 1.x's list, and later Electrum 2.x borrowed (back) one of the new word lists which had no BIP-39 equivalent. Since Electrum 2.x can work with word lists of any positive size, I assume ThomasV saw no reason to create a Portuguese word list of BIP-39 size.

I checked the Electrum 2.x word lists yesterday and they match BIP39 exactly for Japanese, English and Spanish. When you say Electrum 2.x "borrowed back" a non-BIP39 wordlist, are you referring to Portuguese?

@WizardOfOzzie Right, I meant that they used Monero's word lists for Portuguese which had no corresponding BIP-39 list. I've no idea what the plans are, if any, for Chinese, and I've no idea if the BIP-39 French word list will be used, or the partially completed Electrum 2.x one.

yeah, the BIP39 French wordlist has real issues, sharing 100 words with English; https://github.com/simcity4242/pybitcointools/blob/master/bitcoin/mnemonic.py#L44

@WizardOfOzzie We're getting a bit off-topic here ;) ... but I actually disagreed with you in the GitHub PR here, FWIW.


text:
Testing BIP47 test vectors
BIP47 is a new secret-sharing protocol which succeeds BIP64 (stealth addresses).
The test vectors are here.
I am stuck on part 2.iv. We multiply S0 = B0 * a0 (024ce8e3b04ea205ff49f529950616c3db615b1e37753858cc60c1ce64d17e2ad8 *  8d6a8ecd8ee5e0042ad0cb56e3a971c760b5145c3917a8e7beaf0ed92d7a520c = 03f5bb84706ee366052471e6139e6a9a969d586e5fe6471a9b96c3d8caefe86fef).
From that we are looking for:
s = HMAC-SHA512(x, o)
"x" is the x value of the secret point
"o" is the outpoint being spent by the first pubkey-exposing input of the transaction.

What does HMAC-SHA512(x, o) mean, first of all? What is o specifically? And how does this factor in with the test vector values?

I've just had a thought: is it as simple as being the notation for HMAC-SHA512(passphrase, salt)?

Per the creator of BIP47 (Justus Ranvier), it's RFC2014 notation:
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Definition_.28from_RFC_2104.29
https://www.rfc-editor.org/rfc/rfc2104


text:
Regular Expressions for DER signature hex (also req, address, TxIDs)?
I'm using Python (2.7) and its re module for recognition of various Bitcoin data, namely:

addresses, DER sigs, OP Return hexdata, TxIDs

I've been using re.compile: for example, for a valid Tx hash (TxID):
RE_TXHASH = re.compile('^[0-9a-fA-F]{64}$')
if bool(re.match(RE_TXHASH, 'f'*64)):    # 'f'*63 would fail
    print 'valid tx hash!'
else:
    raise Exception("invalid tx hash!")

I'm looking for regex patterns for the following (or input on my current best attempt):

DER signatures: General format "30[sig_size]02[r_size]02[s_size][sighash]"
Bitcoin addresses:  re.compile('^[123mn]{1}[a-km-zA-HJ-NP-Z0-9]{26,33}$')
OP Return hex strings: re.compile('^(6a){1}[a-fA-F0-9]{0,80}$')
TxIDs: re.compile('^[0-9a-fA-F]{64}$')

EDIT: to clarify, can someone help with a regex pattern for this? "30[sig_size]02[r_size]02[s_size][sighash]"

Not all signatures in the Bitcoin block chain are DER. OP_RETURN prefixed outputs don't have to be 80 bytes.

[quote]Not all signatures in the Bitcoin block chain are DER.[/quote] Is there an example for non-DER signature in blockchain?

@Bitcoin I'm looking to recognise just DER signatures with regex, so I'm open to any suggestions for the regex pattern. Re OP_RETURN, isn't the regex saying between 0 and 80? (Honest question)

@amaclin All of the ones with unnecessary amounts of padding on the values are BER not DER. You must use the smallest possible encoding for DER rules.

Yes the regex is saying between one and eighty, but that's not a requirement of the data type.

WRT the OP_RETURN: You're missing the data push byte. The data doesn't start immediately after the return. Also, 80 bytes is standard, but not required by consensus.

@NickODell Expecting a certain data push type is ill advised, push types are malleable and not always used consistently. 80 bytes you could use 0x50 for a direct push, 0x4c50 for PUSHDATA1, or 0x4d0050 for PUSHDATA2, or 0x4e00000050 for PUSHDATA4. Regular expressions isn't ideal for this task, especially for BER signatures.

@amaclin Some altcoins also now contain the bytes to trigger the OpenSSL 32bit consensus failure.

@Bitcoin How did we reach discussing altcoins, DER/BER and OP_RETURN ahead of my question on regexs? Me: I'm looking to recognise just DER signatures with regex, so I'm open to any suggestions for the regex pattern. seems pretty clear and independent of DER/BER classification

For DER sigs, it's possible for R or S to be very small.

DER sigs: re.compile('^30[0-9a-fA-F]{72,136}02[0-9a-fA-F]{0,64}02[0-9a-fA-F]{0,64}[0-9a-fA-F]{8}')

Bitcoin addresses cannot have a 0. Also the {1} is superfluous

Bitcoin addresses: re.compile('^[123mn][a-km-zA-HJ-NP-Z1-9]{26,33}$')

Again, {1} is superfluous for OP_RETURN. Also, the a might be capitalized.

OP Return hex strings: re.compile('^6[aA][a-fA-F0-9]{0,80}$')

TXIDs are fine

Ring a ding ding. Thank you for answering the question: I get that it's SO and pedantic semantics are to be expected...  +250 bounty headed your way for the concise answer!

@WizardOfOzzie You should probably test the regex before accepting the answer.

You might want to consider using '([0-9a-fA-F][0-9a-fA-F]){X}' instead of '[0-9a-fA-F]{2X}', to capture the fact that the hex chars must come in pairs.

I ended up using: ur'''30(?P<siglen>[0-4][0-9a-f])02(?P<rlen>[0-2][0-9a-f])(?P<r>(?:00)?[a-f0-9]{2,64})02(?P<slen>[0-2][0-9a-f])(?P<s>(?:00)?[a-f0-9]{2,64})(?P<sighash>(0|8)[0-3])?'''


text:
Why was Blockchain.info DecryptWallet removed?
https://blockchain.info/DecryptWallet.html has been removed for quite some time. Anyone know why?
PS. FWIW, an archived copy at Pastebin

Your URL is bogus, did you mean https://blockchain.info/DecryptWallet.html ?

Fixed URL Above

Have a look at https://bitcointalk.org/index.php?topic=594570.0 for ways to export your blockchain.info wallet to another client.
As for the why, at this point I would say it has to be bad organization or possibly lack of funding. Blockchain.info has been fundamentally broken for quite some time (a quick search yields a post on bitcointalk over a year old for a still unresolved, somewhat minor problem: https://bitcointalk.org/index.php?topic=271633.0 and if you do a bit of digging you can find plenty more)

How does/did this differ from the import wallet option once logged in? Source code here: http://pastebin.com/r2vFpz4e Is it because of security concerns? Also, given the source code, does the html still decrypt a wallet? I've had no luck, perhaps it's relying on server side JavaScript?

Another option for exporting keys out of a bc.i wallet and into another is here: https://github.com/prof7bit/wallet-key-tool. Note however that it appears this tool doesn't support the full breadth of bc.i wallet formats: it supports version 2 wallets and only the most recent iteration (out of three) of version 1 wallets.


text:
How do Blockchain.info recovery mnemonics encrypt wallet data and what prevents hacking of the algorithm?
How do mnemonics encrypt wallet data and what prevents hacking of the algorithm?
For example Blockchain seems to encrypt all data using a mnemonic yet doesn't hold customer data server side.
What prevents creating numerous Blockchain wallets, recording the mnemonics and discovering the algorithm?
NB. The BCI mnemonic recovery protocol is NOT the same as BIP39

FYI, I've done some research, and it appears mnemonics at blockchain.info for example work like this: [11 words encoding wallet ID & checksum] + [words encoding passphrase, 1 word per 2 character combination]

Edit:
Blockchain.info is open source, the algorithm is public. The mnemonic that they use stores information about your wallet id and your password only.
Previous answer: You should read into BIP 39 this covers how mnemonics map to the values that are used to create a HD wallet the algorithm is very well known and corresponds to the size of the key space needed for wallet generation.  There are generally 2048 words in the wordlist used to create a wallet. A 12 word seed generates 128 bits of information (and 4 check bits). That's 11 bits per word from a list of 2048 words.

Thanks Mark, the question title is ambiguous (I'm changing it now) as I am actually not referring to BIP39 mnemonics, but rather the old (circa 2011-2015) BC.info password recovery mnemonics


text:
Is it possible for corporate interests to incentivize securing alternate Blockchains instead of Bitcoin's Blockchain?
Is it possible for corporate interests to incentivize securing POW of alternate blockchains instead of Bitcoin's blockchain?
Given the large amount of funding and/or "partnerships" announced the last month or so where established companies like Paypal and Klarna are getting into bed with Bitcoin.
I ask this because companies like Blockchain.info are getting significant "Blockchain development" funding and it would appear this is an investment in the blockchain itself:
Blockchain president Peter Smith said:

“The company has grown exponentially in every way over the last 18 months. We are honoured to add investors and partners to the team with deep expertise in
  financial services and consumer technology.”

Also from Scott Ellison (PayPal senior director of corporate strategy):

“We’re proceeding gradually, supporting bitcoin in some ways today and holding off on other ways until we see how things develop.”

Is it plausible/possible for corporate interests to divert miners/investors from Bitcoin's blockchain to another blockchain with better rates of return (perhaps just initially) on investment?
EDIT discussion on this over at /r/bitcoinserious

There is a company named "Blockchain," and there is an unrelated part of the Bitcoin protocol called "the blockchain." Does that answer your question?

@NickODell I've edited Q so the company Blockchain.info is capitalised (as Blockchain), whilst a blockchain is in lowercase - hopefully this avoids confusion

I am struggling to understand the motivation for this question, but I'll take a guess. From the Reddit post you linked, it seems like you're wondering if alternative ways of securing the blockchain will be adopted by companies who have an interest in keeping costs low? I'm not sure exactly what costs you mean here, maybe costs associated with securing the blockchain?
Short answer:
Who really knows? It's possible, but any answer is really just a best guess.
Long(er) Answer
One thing to be noted is that it's not actually companies who build tech around bitcoin that have an incentive to keep blockchain securing costs low. Companies building technology around Bitcoin (and other coins) work almost exactly the same depending on whether the system is secured with PoW/PoS/other, assuming the system meets some base security level. Rather, it's the miners who have an interest in keeping costs low, and fees high. I don't think that mining companies are being invested in as much as companies that are building tech around the bitcoin blockchain.

Is it plausible/possible for corporate interests to divert miners/investors from Bitcoin's blockchain to another blockchain with better rates of return (perhaps just initially) on investment?

What kind of rates of return are you looking for here? If you mean rates of return while mining, then see above paragraph. If you mean rates of return for just using the cryptocurrency, then you probably won't be seeing one that is better than bitcoin any time soon, partially because of bitcoins' spreading adoptance and partially because it is a deflationary currency.
If by rate of return, you essentially mean least costly to transact, then you are talking about the fee structure in bitcoin. One of the problems with bitcoin's current fee system (in the long term) is that the people making the transactions are the only ones paying fees. Or rather, those who are just storing bitcoins are still benefitting from the security while not paying for that security. Inflationary currencies differ in that those who store it pay for the security, in a sense, by the money they have losing value over time.
Coding in a slight inflationary factor might make a currency more appealing to transact with. PoS coins have inflationary factors (as do some PoW coins, this one for example), and from this perspective, I could see companies preferring to store value in Bitcoin but transact in a different currency which has some inflation. So, I could possibly see some companies wanting to invest in other currencies that are cheaper to transact in.

Great answer. Of course, you're right in that the question makes a lot of assumptions.

I also wanted to add, from /r/Bitcoin AMA with Gavin Anderson, http://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfmwso?context=3 , he answered that if Bitcoin didn't become the Internet's de facto currency of choice; "I think it'll either disappear and become an under-the-covers ledger system that Joe-ordinary-consumer never sees.". This was kind of what I was getting at


text:
How can address' hash160 be used to determine information for malicious purposes? (Ie reusing of the same address)
I've been playing around with Richard Kiss's Pycoin app which is clarifying how P2PK works. I see that the hash160 of the value: (0x04) (x-coordinate) (y-coordinate) (for an uncompressed Testnet private key in this instance) gives a hash160 value used to prove ownership of the private key.
How is this detrimental for reuse of private keys if there is no issue with PRNGs providing low entropy? I understand how the Android bug was exploited (to a degree, it reused "random values"), but I fail to understand why only sharing the hash160 in a single transaction can be maliciously exploited. To clarify, I'm not talking about privacy concerns of tracking addresses through the Blockchain.
EDIT: The vulnerabilities in question (as specified in the answer are related to quantum computing and/or EDCSA weaknesses, neither of which exist)

I'm confused as to what you are asking about.  Can you explain what "malicious exploit" you think might be possible, and how it would work?

I'll try to find the link. It was a /r/Bitcoin discussion where the argument was that the Hash160 was obfuscating users' public addresses and the fact that the hash160 is only shared once the txn is broadcast. But for the sake of this question, is there any vulnerability in reusing keys besides compromising economic anonymity?

The potential security issue is that an an EC public key might one day be reversible into a private key using (for example) Shor's algorithm[1]. This does not apply to a hash of a public key (aka address).
Since the public key of a Bitcoin address is revealed in the first transaction spending from that address, it is therefore considered a bad practice to reuse that address (also for privacy reasons)
[1] See https://security.stackexchange.com/a/34942/16036

If your PRNGs are good, you don't lose any security by using the same address any number of times. Some websites claim that addresses should not be reused because that will make your bitcoins vulnerable to quantum computers and/or some newly discovered weaknesses in ECDSA. However, both of these scenarios are unrealistic at the moment, and I think that if they do become realistic, this will be such a big problem for the world's cryptography that you won't be the first victim (unless you are Satoshi Nakamoto).

Yes, it seems it was probably some kind of quantum computing discussion. I think this image from Ken Sheriff's blog is very clear; the 512 bit public key is neither reversible for 512 public key ==> 256 bit private key nor the SHA256/RIPEM 160 ==> public key hash, with the latter being what I was questioning. https://lh4.googleusercontent.com/-p8yVJXqY7fg/UuLaPjMDtyI/AAAAAAAAWYQ/QoenRIBO1O4/s2048/bitcoinkeys.png


text:
HMAC "Bitcoin Seed" for BIP32
Pybitcointools uses the following code for calculating a master private key (BIP32) from a seed:
def bip32_master_key(seed, vbytes=MAINNET_PRIVATE):
    I = hmac.new(from_string_to_bytes("Bitcoin seed"), seed, hashlib.sha512).digest()
    return bip32_serialize((vbytes, 0, b'\x00'*4, 0, I[32:], I[:32]+b'\x01'))

Why - specifically - is the byte string Bitcoin seed used in the HMAC algorithm? When one considers that the byte strings Mnemonic and Electrum are used in HMAC derivations (in BIP39/quasi BIP39, respectively), the labels seem overly non-specific. I'm wondering why the byte string doesn't clarify or specify a version, eg BIP32 V0.1 seed.
None of this is criticism, to be clear! I'm trying to elucidate how these decisions were chosen and implemented, which is often very difficult without being intimately knowledgeable in RFCs, Github etc.
Perhaps this could be explained in context of how HMAC works also?

It is specified in BIP32 (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The SHA512-HMAC function is reused because it is already part of the standard elsewhere, but it takes a key in addition to the data being hashed. As the key can be arbitrary, we opted to use to make sure the key derivation was Bitcoin-specific.

I've clarified the question.


text:
BIP65: "replacing ntimelock entirely"?
BIP65 discusses replacing the ntimelock field with the new CHECKLOCKTIMEVERIFY OP code:

As an aside, note how if the SignatureHash() algorithm could optionally cover part of the scriptSig the signature could require that the scriptSig contain CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. (the CODESEPARATOR opcode came very close to making this possible in v0.1 of Bitcoin) This per-signature capability could replace the per-transaction nLockTime field entirely as a valid signature would now be the proof that a transaction output can be spent.

How is this different from the functionality of ntimelock? (I.e. Why would a signed transaction using ntimelock not be sufficient?)

nLockTime affects transaction validity only, if you make a transaction with an nLockTime in the future (by block height or unix time) it is invalid until that time has been passed. This means that if you sign a locked transaction, you can also just as easily sign a different transaction spending the same outputs that is spendable today.

This is useful if you wanted to make a contingency transaction and give it to a third party which spends the output to a charity if you aren't around to make use of it in a years time. If you are around you can spend it in an alternate way, if you aren't a third party can broadcast the locked transaction to the network once it has become valid.
The limitation is in that you can't prove that funds are actually locked in this state, there's no way of knowing that the person won't just spend around an nLockTime transaction in a different way and bypass the restriction on when they could spend the funds. Setups are possible where a user sends an output to a new key, makes a locked transaction to themselves at another address, then destroys the private key, but this is incredibly flimsy and has no real assurances that the key wasn't retained secretly.

CHECKLOCKTIMEVERIFY is a new proposed opcode that allows you to use the current real time in a transaction script, allowing some more interesting and provable use cases that involve actually locking money rather than a particular transaction. This is closer behavior to how people normally think nLockTime should operate when they first hear about it.

With CLTV, scripts that have different preconditions for spending based on the time are possible. Rather than limiting to a single presigned nLockTime transaction, a person could have every transaction in their wallet spendable by a specific charity key if 2 years pass without them being spent, or a 2-of-3 multisignature could have a contingency backdoor where an additional party can be included if the funds have not been used for an appreciable amount of time.
CLTV also allows for payment channels to be used even with transaction malleability. A mutated transaction can break nLockTime refund transactions at any point, which makes them quite risky at present. With CLTV the payment channel transactions can just timeout and be refunded to the creator without the need for any further interaction.

BIP65 is potentially dangerous to end users as there are pretty much no take backs (if you lock your money for 5 years, there's no back doors or workarounds that will get your money back before then), but that said, that's a user interface problem rather than a fundamental security one. There's little contention about soft forking this change into the Bitcoin codebase in the future.

So, if I'm understanding correctly, CTLV writes un-spendable UTXOs into the Blockchain (until the time limit is valid). What about ntimelock? These Txs wouldn't be written in as UTXOs, right?

Possibly, it depends how you use the CLTV opcode, it's just a switch you can use to decide spend-ability on. A nLockTime transaction is invalid before it is unlocked, a block that includes a transaction before its nLockTime is invalid as a consensus rule. They also can not be broadcast through the P2P network.