text:
How to use NBitcoin for BIP32 wallets
I'm using c# NBitcoin to generate master key at an offline server
ExtKey privateKey = new ExtKey("[My seed]");
ExtPubKey pubKey = privateKey.Neuter();

I will need to give the online server the master public key, and it can generate as many addresses it needs, my questions are:
How do I pass the master public key (pubKey) to this code in the online server ?
BitcoinAddress address1 = **pubKey**.Derive([some client data]).PubKey.GetAddress(Network.Main);

What is the best practice to listen for a payment received on this new address ? I'm working with web requests to http://btc.blockr.io/api/v1/address/unconfirmed/[address1]
My language is c# server side.

when you are doing
BitcoinAddress address1 = **pubKey**.Derive([some client data]).PubKey.GetAddress(Network.Main);

You are getting the bitcoin address, but not the master public key. (ExtPubKey)
A HD pub key have more information than just the pubkey.
The correct code is
string wifStr = **pubkey**.Derive([some client data]).ToString(Network.Main)

Then you can reload it
ExtPubKey key = ExtPubKey.Parse(wifStr)

In fact, the string format of an ExtPubKey have the Network to which it belong, that's why you also have the type "BitcoinExtKey" which represent in object oriented form both : the ExtPubKey AND the Network. If you need it :
BitcoinExtPubKey wif = **pubkey**.GetWif(Network.Main)

Take a look at my book, there is other code samples around HD keys.
Concerning the best practices, there is no silver bullet right now. I created an API called RapidBase which permit you to create wallet and add addresses to monitor in this wallet. (You can find it on github)
You can try it if you want, but it is very unstable for now (API wise), so expect things to change in the future. If you are using blockr, I think your best bet is to request each addresses as you are doing.
If you are using bitcoinq RPC, you can add address, but it takes time since bitcoin core will rescan the blockchain for fetching the relevant transactions each time.
I might be wrong, but for now there is no easy to use solution, exception rapidbase I developed, that is not very stable for now.

But he's not interested in the chaincode - he doesn't need the extended child key. What he needs is a way to monitor an address.

Well, this is a two part question
"How do I pass the master public key (pubKey) to this code in the online server ?"
This is a response to this one.
I'm editing the response for his second question.

Ah, I see. I didn't see that first question.

didn't see the second one :D

See my answer, I wanted to save the Neuter so I can use it as the master public key from which all childs created. If I save the wifStr and publish it on the online server if some hacker find the wifStr can he create from it the master private key ?

you have a wif version of both : ExtKey and ExtPubKey, if you have the ExtKey and want the ExtPubKey, just do extKey.Neuter().ToString(Network.Main)

@NicolasDorier Your book seems interesting, but the "new version" link is not working, only the "old version" one?

////////////////1st offline SERVER//////////////////
//Create Master Private Key with a seed
ExtKey privateKey = new ExtKey("16236c2028fd2018eb7049825e6b4f0191de4dbff003579918de7b7348ff06ac");
//create master public key from this privateKey
ExtPubKey pubKey = privateKey.Neuter();
//save it's wifStr as key to the next server to use and generate all child keys
string wifStr = pubKey.ToString(Network.Main);
////////////////END//////////////////

////////////////2nd online SERVER//////////////////
ExtPubKey key = ExtPubKey.Parse(wifStr);
//The payment server receive an order, note the server does not need the private key to generate the address
uint orderID = 1001;
BitcoinAddress address = key.Derive(orderID).PubKey.GetAddress(Network.Main);
Console.WriteLine(address);
////////////////END//////////////////

////////////////3rd admin SERVER//////////////////
//Now on the server that have access to the private key, you get the private key from the orderID
ExtKey mPrivateKey = new ExtKey("16236c2028fd2018eb7049825e6b4f0191de4dbff003579918de7b7348ff06ac");
Key key1 = mPrivateKey.Derive(orderID).Key;
BitcoinSecret secret = key1.GetBitcoinSecret(Network.Main);
Console.WriteLine(secret); //Print a nice secret key string
////////////////END//////////////////

the code is right, except new ExtKey(string) does not exist. If you have the private ExtKey, use ExtKey.ToString(Network) / ExtKey.Parse(wif)


text:
Does Bitcoin have inherent value if you can fork the project and create a new cryptocurrency easily?
I like Bitcoin and I like the ideas to create a limited number of bitcoins. However, I see a lot of new crypto-currencies. It seems anyone could fork bitcoin, change something in the algorithm, and release a new crypto-currency.
So I'm afraid that one could create hundreds of new crypto-currencies each day without any value.
Is this a plausible scenario?

Yes, this is a real possibility. Effectively, Satoshi Nakamoto created a billion dollar market-capitalization of currency out of thin-air. Of course major corporations are going to attempt their own flavor, it is the nature of capitalism and it is a very healthy reality, which ultimately ends with a satisfied consumer. Progressive companies are forking it, prototyping new designs, and adding improvements. In the end, the quality, scale and technical effectiveness of your product will create the market-demand absent of billion dollar promotional marketing campaigns. BTC is a purely organic, community driven crypto-currency which sells it self.
Currently, the infancy of BTC is very analogous to early 20th century automobile manufacturing. There were hundreds of car companies created in the US only of which 3 major manufacturers survived (Ford, GM, Chrysler). Analogous  to the rise of a myriad of crypto-currencies each of which claims to be better than the previous. How could you trust these crypto-currencies...? That is an unanswerable question which only the market will decide in the coming years.
BTC is the first and most secure crypto-currency; its design and function are superior to many  other proprietary builds.

There are hundreds of chemical elements, but that didn't stop gold from becoming valuable. It's all about people's willingness to trade.
As far as I can tell, you wouldn't really have to change the Bitcoin algorithm. Just run Bitcoin as-is on a distinct network with a brand-new block-chain, and you have a new digital currency. But if you can't convince anyone else to join your new network, you're just wasting your time.

didn't stop gold I'm not sure this is a great analogy. There are plenty of reasons to not use Chlorine or Hydrogen as currency, while Bitcoin and Litecoin are very similar in a technical sense.

There've been papers exploring all the (very good) reasons why Gold alone became the favoured store of value for most of humankind, some of them: relatively scare but not too much, easily findable in pure state in nature (as opposed to silver compounds which need to be broken down or iron mineral to be worked), easy to identify correctly (when platinum was discovered in Peru, it was mistaken at first for a compound of silver), doesn't oxidize, resistant to most acids, it's pretty, it's soft - so easy to work for jewelry, statues, etc.

In a free market economy, the consumers will chaotically and naturally choose the best product.
Those who think they can create a digital cryptocurrency "better" than Bitcoin - however they define "better" - are more than welcome to do so and try to convince others of their reasoning. If the reasoning is sound and people like it, the market will reward the founder with use of their currency!

Personally, I see altcoins as testing grounds for new features. For example, I think that Bitcoin might one day get features similar to Namecoin, or that the mining algorithm might change to something like Litecoin.

source: Stack Exchange

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

sort: votes


text:
Would this wallet backup system work?
I was thinking about a possibility to overcome the 'only stored on one PC' wallet problem! I erase or lose my PC, then I lose all my bitcoins.
Suppose that the wallet, associated with an account number and a strong secret password were backed up on all Bitcoin clients.
What would be the drawbacks/advantages of this solution?

Do you mean all clients in the whole network? Or just a set of clients that you control?

No i mean all clients .. or some clients that you don't control.. Like a de-centralized archive's of crypted wallet. Only who knows password can decrypt and access to his wallet.

In a way, this is how deterministic wallets work: All keys and addresses are derived from a secret pass phrase. The "wallet" in this case is the description of the algorithm, which is "stored" publicly.

Mmmm.. this is not the same what i mean. Suppose i can access to my "wallet" (aka bank account) from any bitcoin client.. simply i insert my "user" and my "password"... because all "bank account" (wallets) are 'replicated' through all clients. This allow you not to loose all coins (money) if you format your pc or get a virus or ... Obviously, there are a risks to have your wallet 'cracked' if you don't use a strong password because anyone can access to all wallets... there are pros and cons to evaluate...

Suppose i can access to my "wallet" (aka bank account) from any bitcoin client, simply i insert my "password": That's exactly what you can do with a deterministic wallet.

Blockchain is ment to hold information important to whole network, why would it bear arbitrary load of every Tom's, Dick's and Harry's wallets?
Also, transaction addresses ment to come and go, so it is not store once, use forever.
Then again, Bitcoin is not thing-in-itself, it relays on many tools and facilities around, so no need to lock it onto itself.
And the killer: you have to keep that strong password somewhere, might aswell keep actual wallet keys there (paper, brain, bytes, whatever)

authors: Сергей Леонидович Климов

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


text:
Bitcoin and Bitcoin Cash blockchain split
What is the safest way to make sure on August 1st that I get the amount of BTC I own in BCC?
For example Coinbase is going to keep all the BCC. So if you have BTC in Coinbase you won't get the equal amount of BCC.
I want to make sure I get the equal amount of Bitcoin Cash as I have of Bitcoin once the blockchain splits.

If you had BTC in Coinbase during the split, Coinbase automatically handled the split for you and provided the appropriate amount of BCC in a separate account.
If your BTC lives in a wallet outside of an exchange that automatically handles the split, you need to use a BCC wallet (like Electron Cash, for example) to read the BTC wallet information, notably the private key. If you have the private key for a specific BTC wallet, that key also works for the BCC wallet.
If you are paranoid, move the BTC to another wallet before trying to access the BCC represented by that wallet, since the same key can be used to empty either the BTC or BCC wallets.
Personally, I used Electrum for my BTC. I swept my old BTC into an Electrum wallet and them moved it to a Coinbase BTC account. After that, I used Electron Cash on the same wallet to move the BCC represented in that wallet to Coinbase BCC account. Don't get confused. BTC sent to a BCC wallet or BCC sent to a BTC wallet are lost, forever.

Ensure you have your private key of the address the BTC was sent to backed up. As long as you have the private key, you will be able to spend those UTXOs on the fork and BTC itself.


text:
Error polling getblocktemplate {"code":-4,"message":"Failed to parse wallet address"}
I am trying to setup a cryptonote pool on my VPS. I am running the coin daemon and configured the wallet rpc.
The config is the same as here
https://github.com/fancoder/cryptonote-universal-pool except the daemon which runs on port 26968. This is my netstat output :
PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN                 1086/mysqld
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN       25062/redis-server
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      28390/electroneum-w
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1017/sshd
tcp        0      0 0.0.0.0:26967           0.0.0.0:*               LISTEN       26867/electroneumd
tcp        0      0 127.0.0.1:26968         0.0.0.0:*               LISTEN      26867/electroneumd
tcp6       0      0 :::443                  :::*                    LISTEN      1176/apache2
tcp6       0      0 :::6379                 :::*                    LISTEN      5641/redis-server *
tcp6       0      0 :::80                   :::*                    LISTEN      1176/apache2
tcp6       0      0 :::22                   :::*                    LISTEN      1017/sshd
udp        0      0 0.0.0.0:68              0.0.0.0:*                           782/dhclient

Nevertheless I get error

Error polling getblocktemplate {"code":-4,"message":"Failed to parse wallet address"}

when i run
node init.js

Any Ideas how to fix this ? I couldn't find anything useful in the net.

This was a simple fix. The wallet address was cut at the end.

please post how you fixed it as an answer so the question doesn't remain unanswered :)

So the fix was that the address was cut in the config.json file due nano not displaying all the line.
So if you run into this problem check if the address is correct :)


text:
Did I lose my Bitcoin cash sending from an exchange to a Bitgo bitcoin wallet?
No transaction is showing up on the blockchain or at Bitgo Bitcoin wallet.

Which exchange? Did you send Bitcoin or Bitcoin Cash from the exchange? Did you send before or after the fork?

It was sent after the fork from a Bittrex bitcoin cash wallet to a Bitgo bitcoin wallet.

Possible duplicate of Bitcoin Cash accidentally sent to Bitcoin address. Can I get them back?


text:
How to convert an Electrum 12 word seed to a private key?
How can I convert an Electrum 12 word seed to a private key?
I heard Electrum has a special type of algorithm where the 12 word seed can't be used on other wallet software; is that true?

Haven't seen a tool, that can do so.
Electrum has a BIP39 based system, with some custom extension. Look for BIP39 and Electrum, this appeared already in bitcoin stackexchange. From (somewhere) there I also got the compatibility list:

https://onedrive.live.com/view.aspx?resid=584F122BA17116EE!313&app=Excel

Internally in Electrum wallet, you can export via menu "Wallet" -> "PrivKeys" -> "Export".

can I extract private key even when Electrum network is offline?

If you export the PrivKeys, you get a sheet with all transactions, you need this.
Right-click in your Electrum in History on a transaction you received BTC on, then click details.
Then you have to look for the corresponding transaction in the sheet you downloaded, and look for the corresponding PrivKey.
Go to your Coinomi and go to BTGold wallet, select sweep wallet, here you can put in your PrivKey, and you will get the BTGold of that previous BTC transaction.
If you have more transactions BTC in your electrum, you need to input more PrivKeys in Coinomi, but they get counted together.


text:
Now that the hard fork is coming Will replay attacks if not dealt with destory the coin's value?
As we all know there's a hardfork coming our way this November.
My question is now that the hard fork is coming Will replay attacks if not dealt with destory the coin's value?
Because if this issue won't be fixed and fast and people could make this so called "Replay attacks" there won't be any point of making a bitcoin transaction since it won't be as "safe" and one coin could lose it's entire value.
Are prices going to drop? and what's the possibilty of these attacks to actually being a reality?
Thanks.

I think that breaks down to a few questions, both difficult to answer, so here's my thoughts:
1) Are there going to be issues relating to replay attacks?
Possibly, which is why people have been pushing 2x to implement replay protection (it's not possible to do this on the current version without making your own fork).  Core have attempted to mitigate this by rejecting BTC1 nodes in the latest release of Bitcoin Core.  But now we have the possibility of BTC1 nodes pretending to be something else so they will be recognised by the Core nodes (which makes little sense as far as I am concerned).  Replay protection may be as simple as waiting for the fork to happen, then transacting with a specific node type you want your transaction on (some light wallets allow you to effectively "pin" trusted nodes), if the network is already segmented then your transaction shouldn't be broadcast on both.
Another option is to get some freshly minted bitcoin post fork (either one will do), move your coins and include this post fork bitcoin, this will be rejected as invalid on the other chain (those coins don't exist there).  You can then safely move the coins on the other chain as the first chain would have those coins as spent (and therefore the transaction would be rejected also).
As to "destroying value", maybe, for some people it could be an issue, however any coins sent on the wrong fork would still be recoverable by the receiving party as the address format hasn't changed, so they could just claim the coins on that fork.  It's a massive hassle though, more confusing than technical issues however.
2) How will the fork affect price?
Hard to say, some expect it to increase the price (as it appears to have done in the run up to the fork) as people will be getting 2 potential tokens, however once it's live, one of the forks may drop in value, with the money migrating to the other fork.  It's safe to expect some volatility, with one side emerging on top, how long this takes, who knows?  As long as one side doesn't have all the hashing power, difficulty will adjust (will likely be slow on the Core chain as most big miners support NYA) and the coin will become usable again.  One of the chains will be slow though, as there's no "EDA" as implemented for BCH.

Thanks for the comment. I guess we will just have to wait and see how it affects our coins and try not to make any transactions in the meantime.


text:
Want to have private key of my brc address
How can i have my private key. Actually the bitcoin address which i have is generated from 'freebitco.in' . They haven't provided any private key.
Please help me in having private key.

The site you mentioned has several hallmarks of a scam or dubious site.

I do not know the site but it is just easier create a new address on a wallet that allows to export the private key and send your bitcoins to it.

Most sites do not let you export a private key because it is a security issue.
If a user can export a private key, then there is a risk that an attacker could export all private keys en-mass.
The preferred way is to generate your own private key, using any of many different websites or software, and then move funds from the coin-service-provider to your own personal address.  Although you do incur a transaction fee, you can be assured that ONLY you know the private key to your funds.


text:
transaction malleability "attack" vectors
are any of the following transaction malleability "attack" vectors currently feasible?
alter scriptsig from:
OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>

to one of:
1) OP_1 OP_SHA1 OP_DROP OP_PUSHDATA <sig> OP_PUSHDATA <pubkey>
2) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_1 OP_SHA1 OP_DROP
3) OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_NOP

so that the corresponding scriptpubkey still evaluates to true:
OP_DUP OP_HASH160 OP_PUSHDATA <address> OP_EQUALVERIFY OP_CHECKSIG

i can't tell if this is handled by point 6 in bip 62 or not:

Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding
  scriptPubKey, is also a source of malleability.

judging by the code it looks like it has been taken care of, but my c++ knowledge is not great...

Point (6) does not eliminate this source of malleability. Rather, point (2) of BIP62 disallows all three modifications you suggested. BIP62 describes the problem:

Non-push operations in scriptSig Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.

And the proposed solution:

Non-push operations in scriptSig Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: Push operators.

one last one - how about a doubling the scriptsig content:OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> OP_PUSHDATA <sig> OP_PUSHDATA <pubkey> - i think this would still evaluate to true, right?

@mulllhausen Point (6) prevents against that. It would evaluate to true with a typical transaction, but it would be a non-standard and not relayed. For transactions in which bip62 goes into effect, it would evaluate to false, though.


text:
Blockchain receive payments API Network propagation
I'm using the Blockchain API to generate an address to receive payments. I received a payment to a generated address, then Blockchain sends the received amount to the address I defined but that transaction is never confirmed and has Very Poor network propagation 1% - 7 Nodes.
There is no problem if I'm using Blockchain to manage my wallet but my bitcoin client running on my machine never sees that transaction so my blockchain wallet has 0.86964083 Bitcoins and my local wallet (with the same priv keys) has 0.84787744 Bitcoins due to the poor propagation.
What can I do to propagate the transaction to my bitcoin client?

This is a shot in the dark, but perhaps you could get the raw transaction from Blockchain from http://blockchain.info/rawtx/$tx_hash and send it from your client with sendrawtransaction.


text:
Is calling the bitcoind RPC multi-thread safe?
My application uses bitcoind RPC with a Python wrapper. I want to write one thread that periodically watches a number of addresses by calling "listtransactions". Other threads might need to call other API commands in the meantime.
Is it safe to use bitcoind in such a multi-thread setup? (maybe I will use multi-processing in the end because of Pythons global interpreter lock).
When I searched for an answer I found:
Are bitcoin commands resistant to race conditions and thread-safe?
But I am not sure if this answer applies to my problem (and I am also not sure whether Pieter's "yes" is a reply to the first or the second question).
Thanks.

It can be done safely but it can also be done unsafely. If each thread uses its own connection, then it is safe. If the threads "fight" over the connections, then it won't work.

Thanks. That is very helpful. I will use then
conn = bitcoinrpc.connect_to_local()
in each thread, to ensure each thread uses its own connection.

Rather than polling for transactions, you can use pynode or bitcoin-sniffer to connect to the node directly and parse transactions as they happen. If the addresses are in your wallet, you can call bitcoind with the walletnotify option set, which will execute your command with the details of the new transaction.

Very useful links. Seems to be a lot easier to use than polling. Many thanks!


text:
Recovering funds after I lost my wallet.dat
I have received the bitcoin way back in 2013 in Bitcoin Core.
At that time I don't know about the importance of wallet.dat - I have formatted my hard disk and install Bitcoin Core again in 2017 but there it didn't show my Bitcoin in my balance. I have my Bitcoin Key.
How can I get my bitcoin back? Please help me!

Do you mean you have the private key for the address the funds were sent to?

Your Bitcoins are gone forever  Sorry.

If you have your private key, you can add it to your wallet with the command
bitcoin-cli importprivkey "<YOUR_PRIVATE_KEY>" "" false
(The false at the end is to cancel rescan at the moment of adding. It could take some time.)
If you do not have the private key associated with the address the coins were sent to back then, they are lost.

No, I don't have private key. I have public key only.
Is there any way I can get my private key from public key?
Thanks

Unfortunately no. If it was possible, anyone could take anyone's bitcoins. Your only option is to try and salvage information from your formatted hard drive using some recovery software.

Is there any place where I can check my Private Kay?

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


text:
Recovering LTC coin sent to a BTC address
I have mistakenly sent LTC coin(Using bittrex) to my BTC wallet(Zebpay). I have not received the coins yet.
The transaction is showing 6+ confirmations on blockcypher and not showing anything in blockchain.info.
Following to this, Bittrex has advised me to research how to remove a private key from a Bitcoin address and import it into a LTC wallet to recover these coins or contact someone from the LTC community for help.
Does anyone know how to resolve this problem?

do you have "private keys export feature" in your Zebpay BTC wallet?

no, how can we import the private key through a different source?

You should get your private keys to spend stucked coins. But I am not sure that Zebpay would help you in it

I sent my LTC to my Trezor BTC wallet. There is a Trezor recovery function that will recover it if it was sent to a Trezor address.
Hope that helps anyone with a Trezor out!

every serious exchange should have a feature like this IMO.

This might be a problem:

How is my Zebpay wallet secured?
  "[...] Zebpay is a hosted bitcoin wallet. That is the private keys of your bitcoins are with Zebpay. We manage the security of your wallet. [...]"

The only way to get your LTC is to contact Zebpay and state your problem:
https://zebpay.zendesk.com/hc/en-us/articles/205420211-Contact-Us

Zebpay has given up and have told me that they cant help

I'm sorry but then there is nothing you can do... Maybe never use Zebpay again and give them bad reviews but that doesn't really help.

Hate to be the bearer of bad news but those puppies are gone.  Two entirely different blockchains with entirely different wallet address formats.  Hopefully it wasnt a large amount.

the blockchain format itself is the same. address format is the same also (and this is the cause of such mistakes). Zebpay is holding private keys and/or has a knowledge how to get them. But I do not think that they will do such things for mistakenly sent coins

Do u have that blockcypher link to the tx?

Also found this obscure link.

https://amp.reddit.com/r/Bitcoin/comments/6sfnl2/segwit_has_been_locked_in_congratulations_everyone/dleu77d/

yes i have the blockcypher link..can it help?


text:
How to transfer bitcoins from old wallet to new wallet? Have no wallet.dat info
I've been researching and trying different things for few weeks now and I hope that you guys will be able to help me out.
I'm attempting to recover my bitcoins from years ago.. but I have no wallet.dat on my backup and was wondering what's the best way to transfer them to a new wallet I've created?
Blockchain does show that I do have some BTC but I have no idea how to get it showing on the Bitcoin Core.
Thanks in advance

If you were using the Bitcoin QT (aka Bitcoin Core) client, then the private keys you need are in the wallet.dat file.
If you can't get that file, and you don't have any other record of the private keys, I'm sorry to say your funds are lost.
If you had used the Electrum wallet instead, you could recover your keys using the 12 word "seed", if you had that.
There were other wallets in use too; if you think you used something else as a wallet, let us know.

Thanks for your reply. I'm able to log into Blockchain without any issues and its showing me a balance.. I do have a 'Wallet Recovery Mnemonic' if I can do anything with that?

I think I've just figured out how to get the private key for it but still have no idea how to go about transferring without it having any implications?

@TomB If you import your private key to a wallet you control (ie not a 3rd part web based one) such as Bitcoin Core or Electrum, then you are still able to get your Bitcoin Cash and Bitcoin Gold from those forks if you so choose. You may like to read more on how to do it safely if you do that though. How to import a private key to a particular wallet is a question that should be asked separately, if you need help with that.

@TomB if you have the recover mnemonic then you should be fine. You can use any wallet that follows BIP 32 for deterministically regenerating your private keys based on your BIP 39 mnemonic. For example: Bread Wallet. Most wallets that follow those standards have a "Recover Wallet" feature. If you do that, you will have access to your BTC and be able to spend them. You don't need to send them anywhere to have access to them.


text:
How do I retrieve bitcoins sent to my email address through coinbase.com?
I have sent bitcoins from coinbase to my email address but there on my email I just see an email that I have received BTC from Coinbase. How do I retrieve those bitcoins from my email to transfer them over to another wallet?

When sending Bitcoin from Coinbase.com to an email address, you are sending the Bitcoin to another Coinbase.com account linked to that email address. So for example, if you had a friend who has a Coinbase.com account and you wanted to send them Bitcoin, you could ask them for their Coinbase.com email address and then send the Bitcoin to that email address, where they would claim it on Coinbase.com. Reference
If you simply want to move Bitcoin outside of Coinbase.com to a Bitcoin wallet, you will need to send the Bitcoin to your public address.

Since you already receive the bitcoins in your
email all you have to do is click verify. Then
You should be lead right back to coin base.
Look at the one that says bitcoins and the amount you receive. You would then press
The sell button after clicking bitcoin then you would put in the amount you want to receive for instants you could say send from bitcoin to my bank account or credit card you used when signing up for coin base. For example you  could  put in 0.07. For your bitcoin and it will automatically show you the amount you will receive. Then hit the  sell bitcoins button
And you will immediately receive a confirmation of when your funds will be available.


text:
How to get Bitcoin Cash from Multibit HD wallet?
Multibit HD still works but is no longer supported so I sent most of my bitcoins to my new ledger nano s hardware wallet.
I now gather there may be bitcoin cash associated with the old multibit wallet that could still be claimed. If so, how can I do that please?

You need to use a Bitcoin Cash specific wallet.  I won't recommend a specific one but here is a list:
https://www.bitcoincash.org/#wallets
Use at your own risk.

Why the down vote with no comment?

It wasn't me that downvoted, but the downvote is probably because this answer is not particularly informative or useful at answering the OPs question.


text:
How to retrieve BCC mistakenly sent to BTC Electrum wallet?
I sent my BCC from blockchain wallet to my BTC Electrum wallet and now I cannot trace them. Does not show in either of the wallets. How do i retrieve them?

Attach link to the transaction on the chain where transaction happened.

Welcome to Bitcoin.SE! You can help the site by marking answers as accepted if they are correct and address the question so that the question does not remain as "unanswered".

Can you find the BCH on a block explorer website? What address are they currently in? Is it one that you control the BTC keys using electrum? If yes, then do the following:
You'll need to take the seed from your BTC Electrum wallet, and use it to generate a new BCH wallet using BCH software. Your BTC Electrum wallet will not show a BCH balance, since BCH is a different network (that uses the same addressing scheme).
It is a good idea to send ALL of the bitcoin out of your wallet, before you generate the BCH wallet using the seed. This is important, it ensures the keys that control your bitcoin remain safe. If the BCH software you use is malicious for some reason, it might check the BTC balance of the addresses you control, and steal the bitcoin from you.
Even if there is a small chance of this, you can be safe by just transferring all of your bitcoin out of electrum first, and then deal with the BCH.
Also, don't transfer the btc back to that wallet afterwards. You can still use electrum, you just have to make a new wallet with a seed that is different from the first one.


text:
BCC sent to BTC paper wallet
I sent Bitcoin cash to a Bitcoin paper wallet. I think it is wrong because the transaction on public key give me 0 BTC.
What can I do to recover my Bitcoin cash?
Thanks!

Are you checking the transaction on a BTC or BCH explorer ?
You have to sweep the private key (of the paper wallet) in a bitcoin cash wallet.
I used Coinomi on Android (be sure to select Bitcoincash) with success.

Thanks! With bitinfocharts.com i see my transaction! Now I try with Coinomi to withdraw. Thanks a lot!!!

authors: ابراهيم العسيق


text:
How to access my Segwit2X currency using private key after the hard fork?
How can I access my second Segwit2X currency, if I own private key, but my wallet does not support Segwit2X currency? Is that private key universal for every wallet? I mean if I can access my BTC or Segwit2X by just my identification with private key in any or some wallets.
How does it work? Will my wallet automatically support Segwit2X or what?

To use the SegWit2x chain directly you'll need to download and build the btc1 full node from the git repo. You then copy your existing Bitcoin (SegWit1x) full node wallet file into the btc1 directory to load your existing private keys.
BUT I wouldn't do that. There doesn't seem to be a safe way to spend SegWit2x coins without risking your Bitcoins. It seems like the recommended approach is to wait until after the dust has settled, with some articles indicating this could take a few days after the fork, and then determine if there's a safe way to spend your 2x coins (most likely by converting them for 1x coins which I'm sure is what you had in mind).
Update: You could take a look at the chainspl.it initiative and their associated design doc to get some additional ideas. Although after perusing the site and reading the doc I'd still say it's arguable whether the "easily handle forked coins" tag can be lived up to.

So there is not more ordinary way for ordinary user? I mean i don't want to download full node, and I don't know how exactly these nodes works. I just heard you need to have private key to access splitted currency. Is there any way by using wallets like these https://www.cryptocompare.com/wallets/#/overview   ?

I'm still not convinced anyone has a foolproof way to accomplish the split yet so I wouldn't recommend taking any drastic action to try and take advantage of the split. As far as wallets go Ledger (https://www.ledger.fr/2017/11/06/preparing-segwit2x-hard-fork/) appear to be very pro-active and by using one of their hardware wallets you get control of your private keys without having to run a full node(s).


text:
How can I make my own pool?
Me and my friends want to make public pool like rublik.com (site have english vesrion).
So, how can we make a similar pool? Maybe there are some open source solutions like p2pool? We want to make a similar pool, maybe someone knows what solutions rublik.com use? We just want to copy their pool.

"possible duplicate" maybe clarify on both if its about a public or private pool, thats two different pairs of shoes...

Running a public pool comes with the obligation to understand the underlying asset.
Rublik seems to have own proprietary software.
To run a public pool you at least need the following:

Knowledge of linux system administration/security.
A dedicated server.
A coder to write/edit a frontend, reward structure and payout process.
Of course the pool software.

Expect if you run a puplic pool to deal with system exploitation and Ddos.
There is opensource pool software available. However, most are outdated, open exploits or other issues. Either code your own, improve existing software or do DD on maintained software (eloipool by luke-jr --> IRC freenode #eligius for example is maintained).
Just a hint:
https://www.google.com/search?q=bitcoin+pool+software&ie=UTF-8&sa=Search&channel=fe&client=browser-ubuntu&hl=en
There are opensource frontends too but those available last i checked are no out of the box solutions.
Even if you get that far you will face the task to create a reward structure with automatic payout process.
To underline that again: 90% of available opensource software needs workovers, some aren’t maintained for over a year, you hardly will find outofthebox solutions for free.

https://bitcointalk.org/index.php?topic=89873.msg989308#msg989308   maybe useful, comments by Ozco.in owner.

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


text:
Sendmany transaction fees
How high are transaction fees for "sendmany"?
Is it correct that using "sendmany" i can send Bitcoins to multiple addresses but only have to pay the transaction fee once?

The transaction fee is based on the size of the transaction (in bytes), among other factors. Each output adds some length to the transaction, so more destinations will mean a higher fee. With the current transaction fee schedule, roughly every five destinations adds an additional .0005 BTC to the standard fee.

Note: I was asking about the standard client and I assume David answered for that. I think in theory fees can be chosen arbitrarily if only a miner includes the transaction. Long story short it seems possible to save some fees using sendmany.


text:
Fee height vs. TX value - limit?
Is there a particular reason fees higher than the transaction volume are allowed?
What about imposing this:
Smallest output must be at least 10 times the fee.
Might reduce Spamdice transactions (thinking of losing bets notification).

Please explain downvote. Am I missing something?

But what if you really needed to pay someone a fraction of a transaction fee? Bitcoin is indiscriminatory in that regard.
Moreover, most transactions have two outputs, one crediting whoever you send your transaction to, and one crediting you back. It is quite easy to send the same small amount transactions to someone while still appearing to be sending a large amount of money in total (the remainder would be sent back to you).
Anyone can enforce arbitrarily low or high transaction fees and modify their software to exclude any and all transactions they don't like (for example, I have heard Luke-Jr's pool does not process SatoshiDice's transaction at all). In the end, it is the will of the people and the miners that will determine the correct fees and rules, not some fixed mandate.

It sure would make things more complicated and lead to more aggregated addresses - always making sure there is enough in an address so that you can send back to yourself.    I guess it makes things too complicated and would only help little. It would mostly hurt Satoshidice but not help against spamming.      The problem with miners choosing the fees is that they are competing heavily. Because of this I think serious changes to the fee rules would have to be enforced by the network as a whole.

Interesting about Luke-Jr's pool not processing SatoshiDice's transactions. Is there any site that catalogs the expected time taken to process a transaction given the input/outputs and the fee payed?

@PeterMichealLacey-Bordeaux Not that I know of. It would probably vary greatly depending on the current load.


text:
How exactly is Ripple decentralized when OpenCoin has so much XRP?
Let us assume in a best case scenario, the Ripple system gets opensourced this year and the 50 billion XRP are distributed fairly to many people in the world.
One of the reasons of having XRP currency is to prevent spam and provide safety to the Ripple network from abusing.
OpenCoin has about 50 billion XRP or even 30 billion XRP without the founders count. So they can technically use their massive XRP to harm the system if they need to. I have not reviewed how many different and harmful ways one can abuse the Ripple network if they have too many ripples.
Why does any single entity needs to have such amount of power over the network? Technically, for us to trust Ripple, we need to trust the OpenCoin entity forever. Even if OpenCoin people are good, what if their accounts got hacked and the XRP is with malicious people?

Looks like OpenCoin sponsored people are downvoting this genuine question. :)

There are people who downvote every Ripple question.

There are only two known "attacks" you can perform with a large amount of XRP.
First, you can dump a large amount of XRP on the market. This will reduce the value of XRP, which OpenCoin would have to report as a loss. The net effect would be that people who hold XRP as a store of value would be harmed. So if you choose to use XRP as a store of value, you are incurring the risk that OpenCoin might hurt you by hurting itself more.
Second, you can sustain a large flow of transactions that would bid up the transaction fee on the network. This would mean that people who wanted to perform Ripple transactions would have to wait or would have to "outbid" OpenCoin for transaction slots. This would cost huge amounts of XRP for every minute you wanted to keep the network unusable. So this attack could just be waited out.
But really the premise behind this is false. OpenCoin's XRP has the same value regardless of how it was acquired. So worrying about this is really no different from worrying that someone with large amounts of Bitcoins might dump them on the market crashing the price. It's true, but people don't do that often because it hurts them more than it hurts anyone else. So, yes, it's a risk.
But generally speaking, there are many kinds of attacks someone can perform at their own expense to hurt you. Someone could flood the Bitcoin network with transactions with a .2 BTC transaction fee each, effectively knocking out Satoshi Dice. It's not rational to unduly worry about these kinds of things because it's so rare for someone to attack you in a way that hurts them more than you unless they have some clear motive to harm you and otherwise you'd pretty much have to worry about everything. And, of course, OpenCoin has no motive to deter adoption of the Ripple network.
(I'm an employee of OpenCoin speaking only for myself.)

What are your thoughts on the recent Ripple crash?

@Pacerier The price of XRP has essentially no effect on Ripple's utility as a payment and exchange system.


text:
What does Litecoin offer over Bitcoin?
Litecoin is different from Bitcoin in the following ways, however none of them are particularly useful and on the contrary are only less worthy.

84 million vs 21 millions: since Bitcoin is divisible upto atleast nine decimals and also micro BTC can be used for dealing with low amounts
Faster blocks, 2.5 minutes vs 10 minutes average: six confirmations of Bitcoin are not equivalent of six confirmations of Litecoin, so Litecoin payments are usually confirmed after many more confirmations. It also wastes mining power because in Litecoin, most of the time miners may start work with non-best blocks.
scrypt vs SHA-256: since scrypt can be relatively efficiently run on CPU/GPU, it means botnets can easily control a lot of hashing power. Also, scrypt is relatively less analyzed and used than SHA-256, so it may not be more secure than SHA-256.

Technically, Bitcoin does what Litecoin does in an equal or better way. Also, Bitcoin testnet can be used to experiment with new features.
Why do we need Litecoin that actually has monetary value (around USD2.7 per LTC now)? Is it just promoted by a group of people who missed the Bitcoin get-rich boat?
Bitcoin is a novel concept and early adopters rightly earn their rewards for the risk they have taken.

not sure why this question is down-voted

I didn't down vote you, but it was probably because your "question" is already biased

Likely the question was downvoted because it's a "push question", that is, a question asked more to influence opinion than to seek information. The equivalent of "How would it affect your likelihood of voting for Jack Smith if you knew he fathered an illegitimate child with his daughter's 19 year old babysitter?"

@DavidSchwartz lol

Well, Litecoin's main aim is to make mining easier for the common man.
The problem with pure SHA-256 mining is that it is not very hard to design hardware that can perform mining at an astonishing speed. We can see this with the currently very much ongoing rise of the ASIC mining industry.
Since scrypt is more complex when it comes to hardware - scrypt not only requires many processor cycles, but also requires intensive memory use - it is harder to design hardware specifically for scrypt mining.
The result of this is that Litecoin mining will be profitable for the average joe for a longer period of time than Bitcoin mining did, when it would be adopted just as fast. Since it does not, the arrival of dedicated scrypt mining hardware will be even more deferred, to the benefit of the miners.
Besides this, I have to agree with you that the other differences between Litecoin and Bitcoin are only minor. Total currency is really not that important since both are very divisible. And faster confirmations are not required either, most Bitcoin transactions are considered valid upon first notice, since it is hard to perform a double-spend attack. (Note that you should better require a transaction to have a fee included when you want to consider it confirmed upon first notice.)
Also, after one confirmation, pretty much all transactions can be considered final.

How do you weigh the risks of botnets dominating this space? I bet the "real" avergae joe is most probably a victim of botnet takeover than actually literate enough to mine litecoins.

Hmm, good point. I have no idea how big a role botnets can play in this story, to be honest.

you're right, a botnet could dominate litecoin.   but at least that's a better use than they're usually put to.

Because it will be easier to mine for the average joe.
There are other innovations also. If you didn't know the Litecoin network can handle more transactions than the Bitcoin network.
You don't know that much about Litecoin.
I don't see why Bitcoin should have a monopoly over the "alternate currency market".
You missed the point.
Botnets can still mine for Bitcoins or they can actually dominate Bitcoin mining. They could have dominated in the past. Just because some guys know how to put a few parts together and have some programming skills that doesn't mean their computers can't get infected with a well designed botnet.
If you didn't know most of the Bitcoins are in the hands of less than 1000 people. Those rich guys could manipulate the system.
This is why you need Litecoins and other alternative cryptocurrencies. It was clear that this could happen from the moment Bitcoin was designed. This would also go against what Bitcon was made for....a free market. This is why Bitcoin was open sourced.
Satoshi Nakamoto deserves money. If he would cash in his Bitcoins I wouldn't hold anything against him.

"The community of users determine a digital currency's value."
Litecoin made easy for the average Joe to mine. This combined with the second mover advantage has became a really powerful initial hype.
As Bitcoin mining stopped being profitable over time, a market need emerged for mining, since the hardware and knowledge was still there. Litecoin perfectly filled this gap.
Personally, I think mining is a need, not a goal, consumers does not benefit from it.

The community of users determine a vitrual currency's value.  Many people are well aware of Bitcoin now... But they missed the boat.  And its limited number will likely keep values high and a little less stable, resulting in the common man being less interested in the concept or its risk.
On the other hand, there's DOGECOIN.  Highly popular, rapidly growing Just released three weeks ago, super cheap, easy to mine, and it has the potential to mine 100 BILLION coins compared to Bitcoin's 21 million.  The number of people that can be involved in Dogecoin (who are aware of vitrual currencies and don't want to miss the boat again), now have another chance.  DOGECOIN'S huge number of coins will mean it will be affordable for a long time - maybe forever - but it also means there are enough coins to supply all world users without having to deal with infinitely smaller percentages of one coin.
Since values are what a currency's community gives it - consider the fact that Dogecoin's community will be much greater numbers AND more world saturation.  Now that's a community, and THAT will be sustaining value - more stable value - which will likely never get to the peak that Bitcoin did, but in my humble opinion, will more likely be the currency of choice for the long term (ultimately resulting in what could be a higher value than Bitcoin).
Lastly, it has something that no other currency has - a likeable "personality".  Go see for yourself.


text:
What is the early history of the BTC exchange rate?
Trading on Mt. Gox, which is now the largest Bitcoin exchange, started in July 2010 at an exchange rate of $0.05 USD. This comment suggests that on May 2010, bitcoins were traded at bitcoinmarket.com for roughly $0.004 USD.
What other exchanges existed this early in Bitcoin's life? What is the earliest/lowest recorded exchange rate?

According to https://en.bitcoin.it/wiki/History:

2009
  October 5 Exchange rates published by New Liberty Standard. $1 = 1,309.03 BTC (and theymos thought NLS was overcharging[3])

It cites http://newlibertystandard.wetpaint.com/page/2009+Exchange+Rate
and
https://en.bitcoin.it/wiki/History#cite_note-2
That first citation seems to have a decent list of pre-May 2010 exchange rates.

That's cool. I still think there's room for more detail in the scope of this question (e.g., how much volume did NLS have with these rates, other early exchanges and their starting rates).

Yes, maybe someone who was actually around (in 'the Bitcoin world') back then could shed some light on the  volume of NLS. Also, I would expect the most volume at the time to have come from OTC trades, so maybe someone can chime in with their anecdotal experience for that time frame.


text:
How do Bitcoin clients find each other?
What protocols or algorithms are Bitcoin clients using in order to find their peers? I learnt that BitTorrent clients may rely on central computers called trackers. Do Bitcoin clients need any kind of central servers or nodes in order to operate?

Bitcoin clients use several methods to locate other clients. The primary method is a list of nodes from a previous connection to the network. The works very well for everything but your first connection or a connection after a very long period of disconnection.
For the case where you have no previous known IPs or they aren't usable, the primary fallback method is by DNS seeds. Several host names (such as dnsseed.bluematt.me) are maintained that resolve to a list of IP addresses known to be running nodes. Should that fail, the client has a list of IP addresses believed to point to stable nodes hard-coded into it.
One method that used to be used, but that has since been abandoned, was having the clients locate each other using an IRC server. That worked similar to a BitTorrent tracker.
Once you are connected to the network, you will begin to receive lists of IP addresses and ports of known clients.

When the Bitcoin.org client needs to discover peers, DNS seeds is the default for the client v0.6 and above.  IRC was the default for earlier versions.

when you guys mention IRC, what IRC network exactly?

@knocte It used to use irc.lfnet.org, joining a random channel between #bitcoin00 and #bitcoin99.

so if lfnet.org went down, that was a single point of failure? what now, who dictates what are the DNS names to lookup?

@knocte: It wouldn't have been a single point of failure because the client had several other bootstrapping methods including several hardcoded "well known" servers. Anyone who wants to can set their client to use whatever DNS names they want. The official client uses a list maintained by the developers. I believe the developers solicited volunteers to run DNS seeds.

funny how a ripple enthusiast came up with this question (me), googled it and found an answer by you :-).. off topic, but had to share!

@HeddevanderHeide I think most ripple enthusiasts are also bitcoin enthusiasts.

Ok. So Bitcoins ARE vulnerable to China's DNS poisoning ? Good to know.

@Taiko Not really, because DNS is only one method used. A bitcoin server needs only one connection to an honest node to be safe.

Problem is. DNS poisoning will also prevent connection to hard coded IPs. So first time connections can't work of the GFW of China blocks it. @David

@Taiko DNS poisoning has no effect on connections to hard coded IPs. You are right that an entity that controls your Internet access can break your ability to use bitcoin, just as it can break your ability to use any other Internet service. (Bitcoin is especially resilient, however, because just one leak saves everyone.)

I would like to consider the situation where the hard coded "known" client fails as well. If DNS fails and the hard coded known client fails, that would it be possible to randomly guess IPs on that port, and try sending signals out to random IPs until you find a Bitcoin node that responds?

There's a couple of methods the client can use. However, unlike David's very good answer, I'll talk about them in chronological order:

The number one way that clients learn about other clients is by connecting to another client and issuing the 'getaddr' command. The standard client has always had that ability. However, there's a problem with this - how do you learn about client #1?
IRC seeding. This is something that's been in since the first version too. It was simple to implement, but ultimately didn't scale. The first version connected to freenode. Then, bitcoin nodes started getting k-lined. Later versions connected to lfnet. Then, lfnet went down, and IRC support was removed entirely. DNS was around by this point, so that was fine.
IP addresses of well known nodes. This has been in the client since June 2010. Still in the Bitcoin client, though the exact IP addresses change every so often.
DNS seeding. This has been in the client since March 2011. This is easier to scale, because DNS is already built to handle tens of thousands of connections.


text:
In overview, what is "Bitcoin Cash" and the hard fork on August 1st 2017?
In overview, what is Bitcoin Cash? How is it different from legacy bitcoin? What is the blockchain hard fork which was supposed to happen on August 1st, 2017? Who benefits from the fork?  Who is disadvantaged?  Why is Bitcoin Cash important? Why is the fork event important?  Is this related to Segmented Witness (SegWit) and the debate on block size?
How will I know that the fork actually happened?
I am seeing questions and answers that assume this knowledge, but I don't see a good overview explanation here. I think bitcoin.stackexchange.com will benefit from having a good overview.
I ask as someone with general knowledge of cryptocurrencies like Bitcoin, and blockchain technology. But I have not followed the ins and outs of the Bitcoin community's debates recently.

If they have different values, can I arbitrage them?

@Valorum, comments are for clarifying and improving the current question, not for asking different questions. You have a good question. It might already be answered elsewhere on this stackexchange. If not, I encourage you to post it as a separate question.

The Bitcoin blockchain needed some protocol updates and there were several views on what those changes had to be. Because the blockchain is completely decentralized any part of the network can create and maintain its own version of the blockchain, that's called a hard fork, and that is what happened on August 1st.
On July 20th this year, the whole Bitcoin community voted at 97% in favor of implementing BIP 9 (Bitcoin Improvement Proposal) on August 1st, also known as SegWit. This basically changes the structure of the blocks so that the signatures header (the witness) are segregated from the actual transactions. From there it is possible to work out an increased block size. While the majority of the community was ready to implement an increased block size (SegWit2x) through a hard fork around November 2017, some big miners, willing to handle large blocks, decided to go ahead of SegWit2x and hard fork the chain, with blocks 8x bigger, right on August 1st hence creating Bitcoin Cash (BCH).
The fork happened (you can follow the forks here) and the first block was mined around 4PM (GMT) on August 1st. BCH starts trading on the platforms that agreed to also implement the increased block size (August 1st was a rough day for crypto-exchanges, some went down for a while). Because both chains share the same history, any owner of Bitcoin (BTC) technically also owns the same amount of BCH. As of now (August 3rd, 1AM - GMT), 16 blocks have been mined on the new chain, as the miners are waiting for the difficulty level to go down (the difficulty of mining a block on the chain depends on hash power, and the new chain inherited the old difficulty level but with only around 20% of total hash power, it'll take some time to adjust).
A hard fork is an important event because this is kind of an update of the whole network at the same time. Any big players could decide to do whatever they want as the blockchain is not some server that you can just update. This implies we can simply guess the outcome of a hard fork based on what information miners decide to disclose, but always stay aware that they can still change their minds.
The real issue here is that the current protocols running the blockchain are not scalable. For a real mass adoption of Bitcoin and other blockchain related technologies, we need to improve the protocols until we figure something stable and scalable. This might take a while and we will likely see other forks like this one with new ideas on how to scale the blockchain.
On to what will happen, this is complex and evolving everyday, but BCH could actually stay around as a bitcoin-equivalent crypto for a while, or just collapse in a few hours, or maybe BCH will survive as a low value crypto like any other Altcoin... really hard to tell. My view would be that one version of the chain will surpass the other one, and I find hard for the BCT to collapse anytime soon. Some might disagree, I must say I'm pretty new to the game (like a couple of weeks), but I put a lot of effort to try to understand what was happening. It is truly interesting to see how we, as a group, are trying to understand and find the ultimate implementation of one of the latest great technology upgrade that is the blockchain.
Best way to stay informed is the Bitcoin subreddit and for a more technical view on the markets the BitcoinMarkets.

Bitcoin cash is a cryptocurrency forked from bitcoin in 2017 during SegWit and is supported by Roger Ver. Believers in bitcoin cash claim this will allow the network to process transactions more quickly at a low fee.


text:
Bitcoin Transaction Fee
Does the bitcoin transaction fee depend on the number of addresses in the proverbial from field or the number of transactions that led to the balance in the addresses in the from field.
eg:
I have 10 addresses each containing 1 bitcoin,is it better to send them from where  they are to another person or if I transfer all the bitcoins in every address to a single address and then sent the bitcoins from there. I am only talking about the transaction fee in the final send to the other person.

Basically, one or a few number of inputs should make no real difference. But at some point the size of the transaction may grow so big that it will start to get less priority over other ones, because miners may prefer lower-sized transactions to get more transactions fees (assuming they would hit regularly the block size limit).
Anyway the workaround you propose is pointless, moving bitcoins separately from several addresses to one unique address prior of the real transaction would cost you even more. The total size of all the transactions you need for that would exceed the size of a unique direct transaction with several inputs.
BTW, notice that the virtual balance your client shows for each of your “accounts” may not reflect the real repartition as seen by the network for each associated address. (It costs nothing to move virtual amount from one account to the other, but it will also not change the way transactions will be build later by the client).

Bitcoin transaction fee depends on the Client and its settings. The Standard Client charges a minimum fee based on the Transaction size and whether the Transaction appears spammy (quite reasonable), but there are code branches that allow you to send transactions without fees.
As the Standard Client is the most predominant client used today, you have to adhere to its rules if you want your transactions relayed in most cases. However, you can always set the fee higher if you are feeling generous or want to make sure the transaction gets included into a block faster.

Am astonished to find that the standard client still enforce these arbitrary limits. It's been a while I have not followed the development of bitcoin. It's a shame that these fees and block size limits considerations have not been sorted out already! Isn't it too late now? Because of that, bitcoin still hasn't got a predictable future (right now it's not scalable, neither in value nor in transaction bandwidth).

@StéphaneGimenez Fees are a necessary part of Bitcoin in the future when the block reward will start going down.

Sorry my comment was a bit of topic, an this comment is also off-topic. I'll delete them soon. About fees yes that's the plan, but right now fees are just a big joke :-) And anyway I don't even think it can work without inflation… bitcoin holders must pay for the costy bitcoin mechanics, not bitcoin transactors, otherwise forks will invariably happen.

@StéphaneGimenez Hmm, do you have that idea described somewhere (like on a forum)? It sounds like an alternative, but one that would need to be analysed on its own.
As for deleting - don't worry about it, comments are useful insights too, and these ones appear to lead to an interesting discussion.


text:
What is the script assembly and execution in P2TR spend (spend from Taproot)
So I have found and fundamentally understand how P2PKH is assembled from inputs and outputs to create a bitcoin forth-like script for execution.
I looked at the SegWit BIP examples section and I found them easy enough to understand as well.
But looking at the Taproot BIP, I've likely reached my limit.  It's very well written, but I just can't get a handle on it.
Can anyone look at my recent testnet P2TR spend (raw-ish JSON) and show me how the witnessData, scriptPubKey, and sigScript data is used to construct a bitcoin forth-like script for execution and validation?  I'm only interested in single-sig Taproot.  After I grasp that perhaps I can expand to multisig-taproot.  I know the python samples are provided in the BIP, but honestly, still just don't get it.
BTW.. I can provide the testnet privkey if needed, though I might need to rebuild the TXN.
I've XPosted on reddit if you lack enough SE-karma to comment.

In the case of a P2TR key path spend, there are no scripts involved on chain at all (except the scriptPubKey with is just OP_1 , and an empty scriptSig). That's quite possibly what makes it hard to grasp, but also hard to answer your question as stated.

@PieterWuille, fair enough.  Perhaps a better formed question: "What data does a node gather to validate a TXN attempting to spend a single-sig-P2TR output, and how does it use that data to do the validation?"

FWIW, the 'tap' utility in btcdeb lets you create/manipulate -- and 'btcdeb' itself lets you examine details of -- taproot stuff, which may be helpful to learn how things fit together: https://github.com/bitcoin-core/btcdeb/blob/master/doc/tapscript-example-with-tap.md (disclaimer: I am the author)

@Kalle, Wow... looks great, I'll check it out!  I actually just finished hijacking some of the python in the bitcoin-core test_framework python just to replicate the pay-to-key key tweaks: https://www.reddit.com/r/Bitcoin/comments/r8wfio/what_is_the_script_assembly_and_execution_in_p2tr/hnoojlm/

Before we start
I realize your question is only about single-sig scenarios, and you want an answer focused on how validation works. I will address these things, but I think I need to elaborate a bit on how P2TR outputs are created, and how scripts fit in first, as I fear it'd be a lot more confusing otherwise.
In what follows I'm going to make a simplification: instead of describing the actual BIP341 taproot rules, I'm going to describe a variant in which P2TR outputs can only be spendable with exactly one script, rather than with a tree of scripts of variable size. This doesn't affect the answer to your question, but avoids the need to explain the tree structure which would distract from the matter.
Constructing a taproot output
In this simplified version of taproot, every output can be spent by signing with a key (called P), or by satisfying a script (called S). The key P can be a key that (provably) nobody knows the private key to, in case you want a taproot output than can only be spent by a script. The script S can be OP_FALSE or so, if you want a taproot output that can only be spent by a key (as would be the case for a "single-sig" taproot). But in every case, both P and S are something.
In the leading example, I'm going to assume P is a public key which someone knows the private key d to. I'm also going to assume the script S equals <P1> OP_CHECKSIGVERIFY <P2> OP_CHECKSIG, which is a script that enforces a 2-of-2 policy with keys P1 and P2, and consumes two signatures from the stack (one by P1, and one by P2). In other words, our taproot output will have a "spending policy" corresponding to P or (P1 and P2). At spending time, the spender can either use the "key path" (P), or the "script path" (P1 and P2). The ways of doing that will be very different.
The first step however is creating the taproot output. To do so, the receivers first compute the so-called "tweaked pubkey" Q. This is done using a tweak function: Q = tweak(P,S) = P + hash(P || S)*G. It has two important properties:

If someone knows the private key d of P, and they know S, they can compute the private key for Q (namely d + hash(P || S)).
Given Q, or given P and S, nobody can find another P' and S' for which Q = tweak(P',S').

Q is still a public key in a way, but it also somehow "commits" to the script S in the sense that only one P and S can be revealed for it. The scriptPubKey in the transaction output will be exactly OP_1 <Q>, so it stores Q without any hashing. The OP_1 signifies it is a version 1 witness output with 32-byte push (aka P2TR). In practice, this is done by the receiver(s) encoding Q into a BIP350 (bech32m) address, and giving it to the sender. The sender's wallet then knows how to construct a transaction output with the intended scriptPubKey. This means the sender knows Q, but they don't know (or care) about P and S.
Spending and validating spends
The taproot spending rules now say that any transaction output matching the template OP_1 <32 bytes> is to be treated as a taproot output, and the 32 byte push is to be interpreted as the (tweaked) public key Q. It can be spent in two ways:

key path: the witness stack of the transaction input consists of exactly one element, which is interpreted as a BIP340 signature for public key Q.
script path: the witness stack of the transaction input consists of two or more elements. The last one is interpreted as the "untweaked" public key P, the penultimate one as the script S, and all the elements before that as the script arguments to script S. To be valid, it must be the case that Q = tweak(P,S) (thereby showing that Q committed to script S, indicating it is permitted to spend), and running the script S with the provided script arguments must return true.

So in the case of a key path spend, the (tweaked) public key Q is just treated as a public key, and spending with it is literally just requiring a valid signature with it. The validation code doesn't know or care that Q is actually tweaked in this case, but the wallet of course does: it doesn't sign with its normal private key d (because that's the private key for P), but with the tweaked private key d + hash(P || s) (the private key for Q). So in this case, the witness stack is exactly [sig(Q)]. Note that by sig(Q) I mean "sign with the private key to Q".
In the case of a script path spend, the signing wallets basically construct a witness that proves "You saw public key Q, but guess what! In fact that wasn't the public key, it's an S-tweaked version of P, and that means I'm also allowed to spend it by satisfying script S!". In our example, that means the witness stack would be [sig(P2),sig(P1),S,P]; the last two elements prove that Q permitted spending by S, and the first two are script arguments to S providing the required signatures. At that point, the validation just proceeds by running the script S = <P1> OP_CHECKSIGVERIFY <P2> OP_CHECKSIG with inputs [sig(P2),sig(P1)].
Why is this useful?
You may now think... ok, that could work, but what's the point of all this?
The idea is that we've discovered various schemes to make a single public key actually do a whole bunch of things, including the possibility of computing an "aggregate" public key out of a set of other keys, such that all individual private keys are needed to sign for the aggregate (e.g. MuSig2).
With that, it is possible for the "inner" untweaked public key P to be an aggregate as well. In more complex spending policies than just single sig (e.g. Lightning) it would then be possible to make P be the aggregate of both sides' public keys, and the "cooperative" case of spending would be just a single signature on-chain, which is very cheap. Moreover, as long as this key path can be followed, the entire construction would be indistinguishable from a normal single sig: in both cases the scriptPubKey is OP_1 <Q> for some Q, and the witness stack is just [sig(Q)].
Some final notes
If you want a single-sig taproot output for public key P, it is in fact perfectly possible to just use Q=P directly, and to sign with its untweaked private key d directly. As the validation code does not know or care about the tweaking aspect in the key path spend, this is perfectly legal. BIP341 recommends against doing that, and suggests still tweaking with the equivalent of an invalid script S instead, to deal with situation where someone lies about their public key secretly being an already-tweaked version of some other key. Tweaking whatever key you're going to use with an invalid script guarantees that no valid script path spend can be constructed with it at all.
In the real BIP341 S is not a single script, but the Merkle root of a tree of scripts, where every leaf can be a different one. The tree can be empty (key path only), consist of a single script (like here), or be a giant tree with lots of different leaves. These leaf scripts also have their own internal version number, which would permit introducing new script features that remain indistinguishable from the current taproot scriptPubKeys, as long as those scripts don't actually need to be used. The last witness stack element in the real BIP341 isn't just the untweaked public key P, but it also includes the internal version number of the chosen script, as well as the Merkle path to prove how the revealed script related to the Merkle root (and the resulting version+key+path structure is called the control block). There are various other changes to the script language (documented in BIP342), to the signature hash (see BIP341), and an additional extension mechanism called the annex, which is so far unused. None of those are particularly important here, but I wanted to mention them to make the link with the actual specification.
Ok, I guess I also haven't actually answered your question of explaining what scripts things translate to. That's because there is no real script change. The taproot spending rules aren't really changing how scripts work at all (apart from BIP342). Instead, they're introducing a layer of spending logic between the transaction validation and script validation. In the case of key path spends, there simply is no script to speak of, and instead there is just a signature. In the case of script path spends, the rules change how it is determined which script is used, and how it is determined to be the correct script, but what that script is nothing more than the claimed script directly.

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


text:
Does Bitcoin-Core sanitize all accesses to DataDir?
I run core in -disablewallet mode, but keep my datadir on a secondary storage volume, which isn't as secure as my primary drive.  Is this an attack vector?  Could someone stuff some data-bomb in one of the datadir files that would serve as a root-kit into my system through bitcoin-core?
Or is the data coming out of datadir sanitized against buffer overrun type attacks.  Is datadir assumed "trusted" or "untrusted"?
BTW, I always use the -conf switch to ensure my bitcoin.conf file is secure and housed on a secured volume.


text:
watch-only wallet with bitcoin-cli
i'm trying to see all tx hashes and the balance for an address i don't own:
$ bitcoin-cli importaddress 1M43pksKTGpBd8J8XzjStjgnX5vie1kpYA
$ # wait 5 minutes while bitcoind presumably scans all txs
$ # for this address
$ bitcoin-cli getbalance 1M43pksKTGpBd8J8XzjStjgnX5vie1kpYA
0.00000000

bitcoind claims this address has no balance while blockchain.info currently shows a final balance of 0.00993754 BTC
why is this not working?
however the listunspent command appears to list the unspent transactions correctly:
$ bitcoin-cli listunspent 1M43pksKTGpBd8J8XzjStjgnX5vie1kpYA
[
    {
        "txid" : "0fdcdeff329b91fb9888720c958d550c39716f92abec4e5b6ff7c53a22bb31c2",
        "vout" : 0,
        "address" : "1M43pksKTGpBd8J8XzjStjgnX5vie1kpYA",
        "account" : "",
        "scriptPubKey" : "76a914dbf61ed2ce1def33a34d89ab7b05ccc25d9cf02288ac",
        "amount" : 0.00010000,
        "confirmations" : 3608,
        "spendable" : false
    },
    {
        "txid" : "db1beb183808e8b41064405d43bd6c684874b5f328bfb565c4e16cc2baaa0d18",
        "vout" : 1,
        "address" : "1M43pksKTGpBd8J8XzjStjgnX5vie1kpYA",
        "account" : "",
        "scriptPubKey" : "76a914dbf61ed2ce1def33a34d89ab7b05ccc25d9cf02288ac",
        "amount" : 0.00983754,
        "confirmations" : 4459,
        "spendable" : false
    }
]

adding up the funds here: 0.00983754 + 0.00010000 = 0.00993754 matches the blockchain.info figure. maybe getbalance only shows spendable funds?

Try getbalance "*" 0 true.
help of getbalance says: getbalance ( "account" minconf includeWatchonly )

i was hoping for balances denominated by address instead of a single number for all addresses. still, cheers for the answer :)

If you like to aggregate by address, you can use bitcoin-cli getreceivedbyaddress "<adr>" 0

good to know thanks. but this isn't quite the same as a balance - its the total received but does not subtract spent coins

That is intentional. Addresses are intended to be one-use destinations for payments, and getreceivedbyaddress can tell you whether the expected amount has been paid to it. Apart from that, all coins in the wallet are treated as belonging to the wallet and not to individual addresses, which is simpler to reason about that about individual addresses, especially when change outputs move coins are for privacy reasons.


text:
blockchain checksig fail
i'm attempting to verify a checksig from a transaction in the live blockchain. it is failing on my debian jessie pc with openssl 1.0.1k, failing on my ubuntu 12.04 virtual machine with openssl 1.0.1 and validating correctly on my debian wheezy pc with openssl 1.0.1e. both are using the same code. the transaction is the first instance of a SIGHASH_NONE in the live blockchain. i calculate the "message" (tx) hash as:
hex: 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a
same thing in base58: 3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB

the signature is:
hex: 30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2
same thing in base58: 381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd
note that this signature does not have the 02 hashcode appended to it

and the pubkey is:
hex: 04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6
same thing in base58: SJa4B8CrqDs6St5KaXMm4KCCksaT7RDcCaRDyKSD6Mbu1WzSwokEq3JwGtfZRz7by6jYD5QmuVhgqsPYc6wTijQq
converts to bitcoin address: 145YPBBWRj4aquewvx59SAWNrSZFT5rvxr

could someone tell me if these parameters pass the ecdsa verification or not? also if anyone knows of an online validator that would be helpful.

i'm trying to verify this with the jsonrpc client but it doesn't work on any machine i have:
#!/usr/bin/env python2.7

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpcuser = 1
rpcpassword = 1
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332" % (rpcuser, rpcpassword))
message = "3zh5uvKWoRjFgKMSLRVqEWXB6YVLsuDKo97yCsCJZ2wB"
sig = "381yXZvFc5V2dx81gRNNpj7ResKUgWA92mkTefemM9gM2kW37b3DGkV5v2BsFq94pSuH1E4jHq9ScHcp6T7Mfg41a7rbZCnd"
addr = "145YPBBWRj4aquewvx59SAWNrSZFT5rvxr"
res = rpc_connection.verifymessage(addr, sig, message)
print res

output:
False

maybe i'm encoding the message or signature wrong for the rpc client? i tried passing binary encoded data to it, but it didn't like that:
File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 125, in __call__
    json.dumps(args, default=EncodeDecimal)))
  File "/usr/lib/python2.7/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/lib/python2.7/json/encoder.py", line 200, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python2.7/json/encoder.py", line 263, in iterencode
    return _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcd in position 2: invalid continuation byte

verifying with pybitcointools works on all machines:
from bitcoin import *
import binascii

msg = "2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
# make sure to include the 02 hashcode on the end of the signature here!!
sig = "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a202"
pub = "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6"
msg = binascii.unhexlify(msg)
print ecdsa_raw_verify(msg, der_decode_sig(sig), pub)

output:
True

the fact that pybitcointools (a pure python implementation of ecdsa) is able to verify the message against the pubkey and signature indicates that it is a problem with openssl and not with the data itself being incorrect.
as per amaclin's comments under his answer, the der encoding for this signature is non-standard:
30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2

this is decoded as:
0x30 # constant placeholder
0x44 # total length = 68 bytes
0x02 # constant placeholder
0x20 # r-length = 32 bytes
0xbb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a # r
0x02 # constant placeholder
0x20 # s-length = 32 bytes
0x04afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2 # s

note that the r value here starts with 0xbb = 1011 1011 - since the most significant bit (0x80) is set then this is a negative number. this would fail the IsValidSignatureEncoding check and be rejected ever since bip66. specifically, this line would cause the failure:
// Negative numbers are not allowed for R.
if (sig[4] & 0x80) return false;

here sig[4] is the first (leftmost) byte of the r value.
so this explains why some versions of openssl will fail this checksig and others will pass it - it is non-standard der encoding which is only compatible with certain versions of openssl.

Yes, you calculated digest 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a correctly.
Here is my piece of dirty code:
static void xxtest ( )
{
  const QByteArray t ( MyByteArray ( )
      .putInt32 ( TX_VERSION ) // 01000000
      .putInt8 ( 1 )           // 01 : one input
      .putArray ( QByteArray::fromHex ( "5f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e" ) )
      .putInt32 ( 1 )          // 01000000 : index
      .putPrefixed ( MyByteArray ( )
         .putInt8 ( OP_DUP )
         .putInt8 ( OP_HASH160 )
         .putPrefixed ( QByteArray::fromHex ( "21c43ce400901312a603e4207aadfd742be8e7da" ) )
         .putInt8 ( OP_EQUALVERIFY )
         .putInt8 ( OP_CHECKSIG ) )
       .putInt32 ( TX_SEQUENCE )
       .putInt8 ( 0 )          // no outputs
       .putInt32 ( TX_LOCK )
       .putInt32 ( SIGHASH_NONE ) );
  _trace ( QString ( t.toHex ( ).constData ( ) ) );
  const MyKey32 digest ( t.constData ( ), t.size ( ) );
  _trace ( QString ( "digest = %1" ).arg ( digest.toStringRev ( ) ) );
  const QByteArray pubkey ( QByteArray::fromHex ( "04f1939ae6b01e849bf05d0ed51fd5b92b79a0e313e3f389c726f11fa3e144d9227b07e8a87c0ee36372e967e090d11b777707aa73efacabffffa285c00b3622d6" ) );
  const QByteArray signature ( QByteArray::fromHex ( "30440220bb4fbc495aa23babb2c2be4e3fb4a5dffefe20c8eff5940f135649c3ea96444a022004afcda966c807bb97622d3eefea828f623af306ef2b756782ee6f8a22a959a2" ) );
  _trace ( QString ( "verify=%1 (expected value=1)" ).arg ( digest.verify ( pubkey, signature ) ) );
  // now test the same with wrong digest
  const MyKey32 temp ( "temp", 4 );
  _trace ( QString ( "verify=%1 (expected value=0)" ).arg ( temp.verify ( pubkey, signature ) ) );
}
//--------------------------------------------------------------
bool MyKey32::verify ( const QByteArray& pub, const QByteArray& sig ) const
{
  return 0 < ECDSA_verify ( 0, constPtr ( ), 32, (const quint8*)sig.constData ( ), sig.size ( ), EC_KEY_pub_key ( pub ) );
}

the output is:
"01000000015f386c8a3842c9a9dcfa9b78be785a40a7bda08b64646be3654301eaccfc8d5e010000001976a91421c43ce400901312a603e4207aadfd742be8e7da88acffffffff000000000002000000"
"digest = 2c7ecdcb2381e657228284398f2f66b2d7d9cf6aa1bd8e39a7300d0b3c8cfa5a"
"verify=1 (expected value=1)"
"verify=0 (expected value=0)"

Update:
Here is small program for checking signatures with dependency only for OpenSSL lib:
#include <QByteArray>
#include <QDebug>

#include <openssl/ec.h>
#include <openssl/evp.h>
#include <openssl/ecdsa.h>
#include <openssl/sha.h>

static EC_KEY* EC_KEY_pub_key ( const QByteArray& pub )
{
  static EC_KEY* eckey = EC_KEY_new_by_curve_name ( NID_secp256k1 );
  const quint8* ppub = (const quint8*)pub.constData ( );
  o2i_ECPublicKey ( &eckey, &ppub, pub.size ( ) );
  return eckey;
}
//--------------------------------------------------------------
int main(int argc, char *argv[])
{
  const QByteArray data ( QByteArray::fromHex ( argv [1] ) );
  const QByteArray sign ( QByteArray::fromHex ( argv [2] ) );
  const QByteArray pubk ( QByteArray::fromHex ( argv [3] ) );

  quint8 tmp [32];
  ::SHA256 ( (const quint8*)data.constData ( ), data.size ( ), tmp );
  quint8 digest [32];
  ::SHA256 ( tmp, 32, digest );
  qDebug ( ) << "data=" << QString ( data.toHex ( ) );
  qDebug ( ) << "sign=" << QString ( sign.toHex ( ) );
  qDebug ( ) << "pubk=" << QString ( pubk.toHex ( ) );

  qDebug ( ) << "digest=" << QString ( QByteArray ( (const char*)digest, 32 ).toHex ( ) );

  const bool v ( ::ECDSA_verify ( 0, digest, 32, (const quint8*)sign.constData ( ), sign.size ( ), EC_KEY_pub_key ( pubk ) ) );
  qDebug ( ) << "result=" << v;

  return 0;
}

excellent thanks. its very strange its failing to verify on two of my pcs! i will test it with the rpc client and also with pybitcointools. if the rpc client fails then it must be a problem with a particular version/configuration of openssl...

oh, yes! the signature has non-standard der-encoding! Just look to the start of it: 30440220bb... - the proper encoding is 3044022100bb... because R-part can not be negative and starts with "bb". Some OpenSSL versions allow this, some others - not. See http://bitcoin.stackexchange.com/questions/2376/ecdsa-r-s-encoding-as-a-signature

to be correct 3045022100bb...

no luck with the rpc client - see my updated op :p

I have never used rpc for verifying transaction signatures. Seems to me that this call is intended for something else. Drop me a mail to alistermaclin@mail.ru and I will send you Qt/C++ code for checking such things

Yes, OpenSSL versions since Jan. 2015 check correct DER in signatures (DSA and RSA as well as ECDSA); that's 0.9.8zd+ 1.0.0p+ 1.0.1k+ and 1.0.2*. http://bitcoin.stackexchange.com/questions/35841/get-latest-blocks-with-bitcoind-on-ubuntu is the same problem.

i came accross bip66 while googling and this addresses the problem.

authors: ภูริวัฒน์ คมขํา


text:
txout script criteria (scriptpubkey critieria)
what is the criteria for a txout script to be accepted into a mined block? is there any criteria at all? the reason i ask is that OP_RETURN is regularly used in txout scripts yet it is not spendable:
case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}

and i have also seen transactions which push elements to the stack which are more than MAX_SCRIPT_ELEMENT_SIZE bytes.
i'm guessing that a syntactically incorrect script such as:
05aa
(ie OP_PUSHDATA(5) <aa>)

would not be permitted?
could someone point me to the code which miners use to validate whether a tx will be included or discarded as invalid (due to its txout scripts). i'm guessing it lies in main.cpp, but i would like to know where exactly, thanks.
obviously anybody can mine a block that is set up any way they like, but presumably there are fixed rules for whether it is considered valid or not - so other miners will know whether to use its hash as their prev-header-hash when mining the next block?

transaction ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767 from the live blockchain contains a lot of syntactically incorrect txout scripts and is useful as a demonstration:
using pybitcointools:
#!/usr/bin/env python2.7

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)

output:
raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01

analysing each of these txout scripts:
01 = OP_PUSHDATA0(1)

this fails because it claims it will push 1 byte onto the stack, but then provides no bytes to push onto the stack
0201 = OP_PUSHDATA0(2) <01>

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack
4c = OP_PUSHDATA1(?)

this fails because it is an incomplete OP_PUSHDATA1 opcode. the 4c byte should be followed by another byte specifying the number of data bytes to push onto the stack, however it is not.
4c0201 = OP_PUSHDATA1(2) <01>

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack.
etc

its funny that the output scripts in this particular transaction each have a different syntactically incorrect use of the OP_PUSHDATA commands. its almost as if someone had the same question as this and wanted to test if any syntax checking was implemented on scriptpubkeys. i'm glad they did this because its a very conclusive way to demonstrate that absolutely no syntax checking (and therefore no other checks either) are performed on scriptpubkeys before they are spent.

You'll find a lot of scripts like this on testnet3, and a smaller number on the main network. Many of them are attempting (and actually manage in some cases) to break reimplementations using obscure and undocumented behaviors.

yep! it broke my re-implementation - that's the reason i'm asking :) but i don't see a whole lot of value for validating testnet blocks - people can put anything in there and there is not much hashpower to even guarantee valid blocks.

You're never going to download a block with invalid contents, because the block would just simply be invalid. The amount of proof of work for this is almost entirely orthogonal. You really shouldn't be reimplementing script, history has shown (bitcoinjs, bitcoin-ruby, btcd) that nobody has the capability to clone the behavior directly, no matter how many millions of dollars are poured into the effort. Unless this is for fun or experience, link to libconsensus and avoid losing piles of money. It's not foolproof, but it means you won't have avoidable mistakes in script execution.

thanks for the warning but for me its purely educational. you never really know something until you can build it yourself from scratch.

i didn't know about libconsensus - that looks really useful!

For a learning experience go right ahead reimplementing. Somewhat unexpectedly, that's how some consensus bugs have been found in the past. The warning was mostly born of people reimplementing and then running million dollar companies on top of it without really acknowledging the risk.

cool. yeah that's another reason for my re-implementation. so far i have always been late to the party - discovering "bugs" well after they have been fixed by bips

Absolutely no consensus validity checks are done on a scriptPubKey. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used.
OP_RETURN is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into PubKeyHash outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An OP_RETURN prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed.

thanks for the reply! but surely if someone builds a block with a syntactically incorrect txout script then no other miners will build on top of it? i'm looking for that criteria - ie for building on top of an already mined block

i have added a last paragraph to the op explaining a bit better...

The output script is never verified in Bitcoin, you can make something that is complete junk (OP_CAT OP_CAT OP_CAT) and that is valid in a block. If there is no way to satisfy the script and spend it again, then the value of the BTC there is simply stuck there forever. This transaction output is similar to your example, it pushes junk onto the stack for no reason. http://webbtc.com/tx/09ca982b6ab313cd7552b9a28e1dabdd37cab5e6ed05bb241579902c5f1e8989 Bonus points if you can work out what it is pushing onto the stack.

hmm interesting. i'm guessing it is still syntactically correct though? eg 05aa would fail? if not then it might be possible to use txout scripts for buffer overflow attacks on users...

i know they cant be used in EvalScript() - that's not my question.

No checks at all, not even on the size of data pushes. It's an array of bytes.

cool. apparently this transaction does exactly that. i need to have a look at the raw hex but once i have confirmed this i will add it into your answer and mark it as the solution. feel free to get there before me :)

i created a new answer, since the results turned out to be more interesting than i thought!


text:
bip 32 wallet with openssl
i want to use a hierarchical deterministic (bip32) wallet but i'm a bit put off by a lot of the libraries which use different ecdsa libraries to the core bitcoind client. for example pycoin uses a natively implemented elliptic curve library, bip32utils uses python's ecdsa library (i think).
while i'm sure these implementations work extremely well, i'm worried that there may be some rare edge cases where they diverge from openssl's ecdsa implementation.

are there plans to implement a deterministic wallet in bitcoind?
are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?
if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?

p.s. i get that openssl's implementation of ecdsa is also not perfect, but it seems to me that consistency (even to the point of reproducing a bug) is crucial with bitcoin.

There is a relatively new HD/Bip32 patch/PR for bitcoind. Check https://github.com/bitcoin/bitcoin/pull/6265.

@JonasSchnelli, very cool. i can't wait for this to be stable!

You would be best off using something that links to libsecp256k1 than openssl, which is in the process of being dropped in Bitcoin Core due to endless security concerns anyway. I'm not aware of any that do, but I will update this answer if I find any.

are there plans to implement a deterministic wallet in bitcoind?

Possibly, there's currently some planning going on with this, its at least likely that the current wallet will be deprecated and replaced with something more separate from the actual daemon. The current wallet is very heavily tied into the client in a lot of places, and has some massive dependencies like BerkeleyDB which are completely overkill for a key value store.
The current train of thought and some code is partly mixed into the bitcoin-dev logs and also on github. You shouldn't be using any of this with real money though, it is likely to be unstable for a long time.

are there any bip32 wallets which call already-existing-functions in bitcoind wherever possible?

None I am aware of, most wallet software currently developed is either built on BitcoinJ (which numerous privacy and security considerations), querying some remote service (privacy and massive security issues), or something home brewed. Generally key management through JSON-RPC is pretty awful so that is somewhat understandable.

if not then what level of risk is involved in using bip32 wallets which rely on non-openssl ecdsa libraries?

It's good you're thinking about this sort of thing to begin with.
Depends on the library, but the worst possible outcome is that a software implementation bug causes all of your money to be lost or stolen. This isn't unreasonable to suggest, and it happens almost constantly through the history of Bitcoin. Blockchain.info rolled their own RNG and has lost funds on a number of occasions due to it, Mt Gox wrote their own wallet and lost a pile of money when a function errored out and they sent their money to the pubkeyhash null, Bitcoin Armory found the ECDSA code they used leaked private keys through the signature. There's bound to have been more mistakes but these are the ones that have been made public.
Pretty high levels of risk, really.

Have you got a link re the Armory issue? Never heard that. MtGox I remember though; 76a9140088ac is a problem since it's not RIPMD8 :)

They imported some code from another party, audited it and found the RNG for signing to be completely broken, implemented a fix, and then left the fix commented out in the release version. Armory CVE-2014-002


text:
What is a Blob Vault?
The Blob Vault is a part of the Ripple project.
What is it?
The project should get a reamdme.

The "blob vault" is a very simple encrypted storage system used to store Ripple wallets. Your Ripple wallet stores your annotations, named accounts, and so on. You can create a new wallet with the same secret and get your funds back, so losing your wallet does not mean losing your funds.
The guts consist entirely of about 100 lines of Javascript.

Thanks for this answer. Not much information to get here https://ripple.com/wiki/Blobvault nor on the github page