bitcoin wiki states that
OP_RETURN:

  "[...]Marks transaction as invalid. A standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network[...]"

There's no point in a signature of an unspendable output I guess but I might be wrong here.

I found chapter 7 of mastering bitcoin helpfull where it explains the
"Data Recording Output (RETURN)."

Also check this blog post for a different spin on it.

I'm very interested in the colored coins idea but noticed that active implementations are rare from what I could find.

Coindesk reported coinprism shut down in 2018 and the underlying protocol open asset hasn't had any commits in years.

Same goes for colored coins by Colu github repo.  Colu announced a colored coin lightning integration in 2016 which I'm also starting to investigate as an alternative but their demo site is also down.

Counterparty makes use of op_return so you might want to check that out.

You should also check out this post which gives a colored coin example for the  Omni Layer that @Murch mentioned in his answer.


Why is the Schnorr verification formula working and actually verifying the validity of a signature?

To prove the validity of the signature, we must see that the tuple (R,s) actually came from the private key x. In particular that s was derived as s=r+cx. Obviously, we should not possess the private key x (which is the reason why we need this verification equation) so

Looking at gs = RXc, we realize that we know (R,s), X and c (since c = H(X,R,m) and the public key X is known). As the generator g is also known, we can actually compute both sides of the equation.
Since s=r+cx, we know that gs = gr+cx
Since we do these calculations in a cyclic group of prime order we can apply the following rules: ga + b = gagb and gab = (ga)b (As far as I understand, this is the reason why the group needs to be cyclic and of prime order.)
Thus, gs = gr+cx = grgcx
Recalling R = gr and entering it into the equation from 4. we get gs = Rgcx
Recalling the other rule from 3. we have gs = Rgcx = R(gx)c = RXc

This is exactly the equation that was supposed to be shown.
Note the interesting fact that as mentioned in 1. all data needed to verify the equation is known but producing the data can only work if x and r are known. That is why the owner of x can produce the signature and others can verify it.


Relative licensing restrictions of Ethereum and other projects- Open Source?

Is Ethereum open source?

Yes. You can find all the source code on Github.

Technically, Ethereum - as in the idea - is open source since you can read the full specification in the yellow paper.

Ethereum - as in the software - is open source and you can find all major and minor implementations on Github: geth, mist, etc. (GPL, LGPL)

  But then what about the Ethereum Foundation?

Yes. You can find a general statement here


How do I import to MultiBit from Blockchain.info?

Step one : Update your Multibit, normally since 0.3.4 it can import Blockchain.info
https://groups.google.com/forum/?fromgroups=#!topic/bitcoin-multibit/G87Y3e1-0Ak

Anyway, if it's not working you can try this :

Go to Import/Export in Blockchain.info

Now "Export Unencrypted", change Base58 by Bitcoin-Qt format and take the key after "priv".

Now go to Multibit and EXPORT (yes export) your wallet WITHOUT password.
Edit the file exported and you'll see several lines with ADDRESS (whitespace) DATE

Replace address with the blockchain's address. Change the date by the date you created the account (or a few time ago).

Now save and import this file in Multibit, et voilà !


Bitcoin Core LevelDB Index saves forked blocks

They're kept because it is complicated to remove them (it would require rewriting the block storage files), and there is hardly any cost to keeping them (they're a small fraction of the total). Furthermore, close to the tip we want to have forks available, in order to be able to reorganize quickly if one of them ends up becoming the main chain.

More technically, the $DATADIR/blocks directory for Bitcoin Core is not a representation of the blockchain. It's a store of all valid blocks we've ever downloaded. Which out of them end up being considered the main chain is a different issue, and dealt with independently.

Also note that in pruning mode all old blocks are removed - including these small forks.


What criteria should be taken into account when selecting nodes to create new lightning channels with?

I agree with Alex Bosworth and I have pointed this out about one year ago when I have filed an issue about the strategy used by the LND autopilot which basically looks for nodes with a high channel count. This is one of the reasons why I have created a standalone autopilot and provided an integration for c-lightning.

There are several kind of information we can look at (my autopilot currently only looks at the first ones):

Network topology:

How can I increase my centrality (e.g. by connecting to central nodes)
How can I increase my probability to have well funded routes by connecting to points where a lot of liquidity is floating around
Improve the network topology by increasing the amount of triangles
Geography: It is likely that you pay to services where you live and therefor you might want to connect to nodes that have a similar geoip as yours.

Node Provenance / properties:

age of Node (seen by oldest channels)
age of channels (seen by the blockheight of funding transactions)
uptime of the node (can be tracked via the gossip messages and the gossip store)
Routing fees of the node
Reliability of the node to forward payments (can be tracked by doing fake 1 satoshi payments to yourself over different routes)

most of the stuff that I mentioned here has been taken from my blog article about autopilots. In general I hope that better autopilots will emerge because I think this problem will be hard to decide by humans without investing a lot of time.

Finally another strategy could be to create routing tables in a similar way as the border gateway protocol does on top of IP. In that case nodes would share partial information about the channel balance so that we would have a better overview of where liquidity is missing.


Recover bitcoin wallet with old Private Key

The problem might be that blockchain.info wants the WIF (wallet import format) instead of the private key. You might try to find some tools for converting the keys you have in WIF and then try to import them.

Make sure not to give away your keys in the process of converting (I wouldn't trust online tools)


List of companies that has Implemented their own cryptocurrency or Color Coins in their business?

This question is too vague, like asking list of companies that use arrays in programming. Colored coins are programming abstractions(just a type of data structure) and when truly used for a technical reason(not for crowdsale) they are under the hood.
(At work, I have used it as a mechanism to account for scarcity of a resource.)


How to transfer BTC balance when I have Private Key?

Yes, but first u need import your private key in wallet app, fews mobile apps support this feature, blockchain.info wallet (https://itunes.apple.com/br/app/blockchain-wallet-bitcoin/id493253309?mt=8) is the only that i know,under menu/address/+ (plus button). This will open your camera to scan your QRCode private key in WIF format (51 characters).

In case you dont have private key QR code,  can use something to genarate a QRCode, prefer audited and offline code, for example: (https://raw.githack.com/EquestrianBit/equestrianbitpaperwallet/master/index.html), in menu "2. print front"\"my own key", before put yout private key, turn pc offline, only for security questions. All code run local in browser. After get your QR Code, have attention to recommendations in: (How do I send Bitcoin in paper wallet to other person?), like @ugam-kamat told.


What would the effect of a very long bear market be on the Bitcoin economy?

From my understanding, the difficulty of the network will still keep increasing when the "target" block is mined, regardless of the number of miners (yes?)

No.

The difficulty readjusts every 2016 blocks, based on the average time taken to mine the previous 2016 blocks.  If the average is less than 10 minutes, the difficulty goes up.  If greater than 10 minutes, the difficulty goes down.

The rate at which blocks are mined is, on average, proportional to the total hash rate of the entire network.  So if mining power leaves the network, then blocks will be found more slowly, and at the next readjustment, the difficulty will decrease.


Why do wallets use multiple private keys instead of one each?

Why is that so, don't you only need 1 private key to hold all bitcoins and manage them?

Sure you could use only one private key and its associated address, but that is not recommended. It is more secure and more private to not reuse addresses. Instead you should use a new address for every transaction you receive and for every change output you make. Thus your wallet will have multiple private keys for the multiple addresses that you are using.


Bitcoin testnet not connecting to hardcoded ip addresses

These are seed nodes, not nodes that are connected to for a connection. A seed node means that it is a node that will be connected to in order to get addresses of other nodes to connect to. That connection will not be maintained; rather it is temporary.

If you want to connect nodes to each other, you should not be modifying the seed nodes at all. Rather you should be using the -connect=<ip> option (or add it to your bitcoin.conf file) to connect only specific nodes.


Do I have to know all my private keys for sending a "big" amount?

Private keys are not for using previous transactions, they are for using previous transaction outputs.  A single transaction may have many outputs, and many different people may hold the keys to those outputs.

When you send a transaction, you need to reference one or more unspent transaction outputs (UTXOs) to use as inputs of your new transaction.  The sum total of these UTXOs must be greater than or equal to the amount you wish to send someone (minus network fees, of course).  Any leftover can be specified back to you as "change" in the form of a second output on the transaction that is paid to an address you own.

  But what if I want to send a big amount of BTCs but I only have recievied many small amounts? Would I then have to mention each private key for each transaction that I can send this big amount?

You would have to reference all the transaction outputs that you wish to use.  This is simply how Bitcoin works.  However, you don't "mention each private key", since you should never share your private keys with anyone.  What you need to do is sign the transaction with the private keys, which is what lets the rest of the network know that you are allowed to use those UTXOs.

I know this all sounds complicated, but don't worry; your wallet handles all the complexities for you.


Could Bitcoin be based on accounts instead, more like banks?

It could, yes. Ethereum works on something similar to an account system, at least as far as ethereum balance is concerned. Both models are valid, and have their benefits and drawbacks.

The UTXO model allows for great parallelism and privacy. Each transaction can create UTXOs to new addresses, and different UTXOs can be spent independently and parallely.

The account model requires some form of ordered execution (achieved via a nonce in ethereum). Moreover, a single transaction cannot combine balance for two different accounts in current implementations, while you can combine UTXOs from as many addresses are you wish in a single transaction.

As to why Bitcoin chose a UTXO model over a balance one, I don't think an authoritative answer exists on that. It's what the creator(s) of Bitcoin started with, and there is no pressing reason to change it.


Monitoring BIP125 transactions in the mempool

The txid will change, because the transaction has a different effect. It will have more/larger inputs or less/smaller outputs, possibly combined with other changes.

The link between the two transactions is that they conflict. This means that they directly or indirectly depend on spending the same predecessor output. As every output can be spent exactly once, both cannot end up in the same chain.


How to integrate Blockchain Wallet API V2 to php

You need to run a local nodejs service. From there you can then integrate with php.

As of January 2016 Blockchain.info made changes to the wallet API service that now require you to run a local nodeJS service to handle the calls. This will require you to have root access to your webserver so you will need to use a VPS instead of a basic shared web host.

Create an account with blockchain.info, and register an email
address.
Request an API key here https://blockchain.info/api/api_create_code
Login to your blockchain wallet, goto account settings, IP Restrictions and check the box to allow API access
Goto DigitalOcean, register, create a new droplet, goto one-click-install and choose the MEAN stack Other options are up to you, I chose $5/month and IPv6
Open your console or SSH through putty
type root, enter your password, create a new password
Now you're in!
type sudo apt-get update
now install nodejs
type sudo apt-get install nodejs
press y to accept
install NPM
sudo apt-get install npm
y to accept
install blockchain-wallet
type npm install -g blockchain-wallet-service
if you see some warnings or errors, don't worry
once complete verify it installed
navigate to usr/local/bin
type node blockchain-wallet-service -V
if installed it should return with the version number
you can now launch the service, but first we will want to install apache and PHP so we can interact with it outside of nodejs
Navigate back to root
Install Apache
type sudo apt-get update
type sudo apt-get install apache2
Install PHP
type sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt
Install curl
type sudo apt-get install php5-curl
Restart your VPS reboot
Launch the blockchain-wallet-service
navigate to usr/local/bin
type node blockchain-wallet-service start --port 3030
Login to your wallet using the below code

$url = "http://127.0.0.1:3030/merchant/YOUR-GUID/login?password=YOUR-PASSWORD&api_code=YOUR-API-CODE";
$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_URL, $url);
$ccc = curl_exec($ch);
$json = json_decode($ccc, true);
var_dump($json);

Save the above and run it on your server. The file should keep spinning and loading since blockchain doesn't recognize the IP address. Wait for it to timeout about 60 seconds, and then check your email. Blockchain should have sent you an API access attempt showing what IP tried to connect. Follow the link and authorize the attempt, also the IP address from the email and whitelist it in your wallet account settings.

Now try running the file again.
If you did everything correctly you should see a response that lists your GUID followed by Success TRUE

Now you're connected and you can start sending requests with your wallet.

The calls work the same as version one, except you will send your requests through this service instead of get requests to blockchain.info.


It is still unclear how Satoshi chose all the constants present in the Bitcoin protocol (10 mins blocks, 21 million coins, 2016 blocks intervals, etc...).

While we'll never know for sure the full justification until Satoshi manifests itself, we can try to come up with reasonable ones ourselves.

For example, it is supposed the total number of satoshis in existence has been chosen to fit in 64 bits (using a number larger than 64 bits would have made the implementation more complex), making the difficulty interval a power of 2 simplified a lot of maths, etc..


Failed transaction, but my wallet shows 0 balance

According to the Blockchain record for address
1MhnRVvDTHGMSRdSRU5sP7vFH3aMExBAc9

Date
Transaction ID
Confirms
Description

2021-01-25 12:56
8c038b...c3fb2f
2691
Money received from bc1qq9...6cfvgq

2021-02-02 15:33
1708b5...935604
0
Failed low-fee  transaction, now invalid

2021-02-12 14:08
a77bb6...26273d
5
Money sent to 1EqnaM...WQGW6y

how can I get back my BTC from the blockhain universe?

Whoever knows the private key for address
1EqnaMiP676iSxMASjtKimz1k6GbWQGW6y now has control over that money.


I do not understand why some samples use port 8332, some 8333, etc.

Port 8333 is the port that bitcoin uses to connect to other nodes on the network. Port 8332 is the default port for a bitcoin RPC interface. To connect with RPC, use port 8332 or specify a different port with rpcport=<port> option


This is specific to Bitcoin-QT and the bitcoind daemon. Other clients have to provide their own command line options and API to implement this functionality. Option and command names will likely differ in syntax and semantics.

Electrum for example provides console access to its internals.


The most apparent weakness is the following: If an attacker has enough hashpower to build an alternative branch starting with the current block, and to be ahead of the network once that block is pruned; he can rewrite the entire history completely, assigning bitcoins arbitrarily among the addresses he chooses.

This can be alleviated with archive nodes which are consulted in times of emergency.


What are some interesting applications of Taproot "smart contracts"?

I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script "framework" more than they are improvements to the smart contracting "functionality".
All Bitcoin scripts can do in practice is enforce combinations of conditions on signatures by certain (sub)sets of signers, timelocks, and revealing hashes. At a conceptual level, this does not change with Taproot - everything that can be implemented using it can be implemented without Taproot too.
What it does do is:

Make certain things smaller/cheaper (but sometimes at the cost of higher signer complexity).
Make certain things more private.
Make certain things easier to do.
Add mechanisms through which actual new conditions/features can be added later.

In some cases, these advantages can be very substantial though - making the difference between feasible and infeasible in practice, or between actually incentivizing more private constructions or not.
It's hard to give a comprehensive answer what that entails, as it's akin to a new programming language, and there are presumably many things it enables that haven't been discovered yet. I can give a few examples though:

The "Taproot" function itself means that any output, regardless of how complex its script is, can be spent using a single signature on-chain if all signers agree with spending (which also reduces their costs, but it may complicate the signing procedure). This applies to escrows, cooperative Lightning closes and various other things.
Various kinds of multisig become cheaper even when the "optimistic" taproot single-key spend can't be used, either through key aggregation (one key representing multiple people), or MAST (just revealing a script that embodies the exact condtions that were satisfied, rather than revealing all possible conditions). The advantages of key aggregation are in theory already possible using multiparty ECDSA, but that is significantly more complex than what is possible with the Schnorr signatures introduced by BIP340, and not used by anything in practice (as far as I know).
Atomic swaps, which can be used as a new privacy tool, are also in theory possible using multiparty ECDSA, but become a lot simpler using Schnorr based adaptor signatures.


Is it legal to embed a miner in another open source program for benifit of the programmer?

Well, lets look at the outcomes for the user:

your user burns hundreds of times their normal power usage mining, thousands of dollars of their money goes into their power bill
your user potentially ruins their hardware (Mac hardware will die, there's no question of that)
your users computer becomes sluggish and unresponsive
their virus protection removes the miner, as they're almost always marked as malware

The outcomes for you:

you make a couple of cents a day
you look like a complete dirtbag to your users

Doesn't seem worthwhile to me. Just ask them for donations if you really think your software deserves financing.


How can I know which user made which BTC transaction?

You give each customer a different address. That is the only reasonable approach.


settxfee sets the transaction fee per kilobyte, as that is the relevant unit for prioritization on the network and in blocks.

With sendtoaddress the size (in bytes) is not known ahead of time, so you can't set the exact fee.


If I understand your question correctly you want to take m/0h public extended key:

xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw

and derive m/0h/1 public extended key?

These are my values:

version: 0488b21e
depth: 02
fingerprint: 5c1bd648
child: 00000001
data: 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c
chain: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19

What is b8b9c580 in your result? //edit: I am guessing it's the checksum.

chain input to HMAC: 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141
data input to HMAC: 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc5600000001
Calculated hmac: 4eb9d78157bae7a24115001621c4d91e3a3110e11e143c5259eaa4e55c5ec4bf2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19
left: 4eb9d78157bae7a24115001621c4d91e3a3110e11e143c5259eaa4e55c5ec4bf
right: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19

Looking at your values, they are correct except the HMAC result. In python you'd do:

I = hmac.new(chain, data, hashlib.sha512).digest()

I used bip32utils python library to present the result, the end result (m/0h/1 xpub) is correct.


If you have technical problems with Tradehill, your first step should be to contact them about it.

It's not clear to me in what capacity you want to replace Tradehill. If you want an exchange then Mt. Gox is an obvious possibility, or any one of the exchanges listed here. If you want an eWallet, most exchanges are good for this too, and flexcoin is another possibility. If you want merchant solutions, check out bitpay.


Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?

In order to be sure that an address balance is correct, you need to check that all the transactions on that address are valid.  So in order to generate a list of addresses and balances that you trust, you must first download and verify the entire block chain.

Actually, the way Bitcoin works, what you actually need is a list of unspent transaction outputs (UTXOs).  When you create a new transaction to spend coins, you don't just debit an address; you have to reference one or more specific outputs from previous transactions that you are spending.  Those previous outputs then become unusable, so that you can't spend them again.

Bitcoin Core does actually generate an indexed database of all UTXOs, and refers to it when checking transactions for validity (since this is much faster than searching back through the block chain directly).  This is the closest analogy to the "ledger" you proposed.

Once you've done this, you could delete the block chain itself and just keep the UTXO database; that is basically what the -prune option does (see How can I run bitcoind in pruning mode?).  However, remember that Bitcoin is a peer-to-peer system.  So you keep the block chain so that new users can download it from you.


What happens when an attacker completely controlls your Internet connection?

Yes, the scenario is possible. The attacker has two possibilities: censoring data sent to the network (likely your transactions) and censoring what the nodes sees from the network.

In the first case the isolated node will attempt to resend transactions that belong to it until they get invalidated or committed into the blockchain.

In the second case the isolated node will not receive incoming transactions and eventually will not receive blocks (if these contain censored transactions). It is however not possible to fool the node into considering transactions as confirmed without the attacker also producing a valid proof-of-work.

The same argument is valid for Satoshi Proof and Namecoin, you can hide transactions, facts and domains, but you cannot inject wrong information.

Once reconnected the node will synchronize with the network (download blockchain & send its transactions) and eventually be up to date.


What if you wanted to decrease anonymity?

Trying to build a centralized credit system would require a mint, which is why this protocol was build in the first place. We don't want mints and on top of that we don't actually need mints for most functions. I would suggest you take a look at those whole new possibilities that come along with this protocol, such as coloring, escrow services, etc and forget all about the old-fashioned and in many cases incapable credit scoring system. Or, if you insist, try to make use of the all-public transaction log after you have associated an entity with a public address, maybe with a micro-payment or the such.


How bitcoin daemon search nodes to connect? What file in github
responsible for this? How they often change?

Bitcoin use peer discovery to find nodes to connect to, some are hard coded in the file bitcoin/src/chainparams.cpp of the bitcoin core client available on github.
You can find more information here:
https://stackoverflow.com/a/19956156/1616622

How is the veracity of the data of these nodes checked?

There is no need to check them manually that is the beauty of decentralized blockchain, if someone try to trick other nodes by using wrong data like a wrong blockchain the other nodes will see it because of the bitcoin protocol and ban him


Lost my old-Electrum 12-word mnemonic seed order

If you are certain that the 12 words are the correct words but merely in the wrong order, and you know the addresses from the wallet, it is possible to brute force: there are 479,001,600 possible combinations, which isn't too many.
Here is an example of a tool that can help you with this: https://github.com/3rdIteration/btcrecover/blob/master/docs/BIP39_descrambling_seedlists.md
https://github.com/3rdIteration/btcrecover/blob/master/docs/Seedrecover_Quick_Start_Guide.md


What are the sizes of single-sig and 2-of-3 multisig taproot inputs?

Taproot generally has two ways of spending. The default way is to spend the output using the key path: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32.

The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path to one of the leafs, and the arbitrary segwit v1 script contained in the leaf, and then to fulfill the spending conditions of this script.

In the following, a 2-of-3 spending condition is split out into three 2-of-2 conditions:

2-of-{A, B, C} = (A && B) || (A && C) || (B && C)

The assumption is that two of the keys are hot while the third is a backup key for recovery. The default case of spending with the two hot keys is aggregated into the root path pubkey using MuSig. The other two spending conditions using the backup key are stored in leaves of the tree. Two variants are explored: one where the backup key is capable of participating in MuSig signing, another that falls back to a simpler multisig scheme where signing is non-interactive e.g. because the backup key is airgapped and the multiple roundtrips required for MuSig are inconvenient.

Key path spending costs

* outpoint (txid:vout): 32+4vB
* scriptSig size: 1vB
* nSequence: 4vB
* num witness items: 1WU
* witness item size: 1WU
* signature: 64WU

32+4+1+4+(1+1+64)/4 = 57.5vB

Control Blocks

Control blocks are used to reveal the script path and prove the inclusion of the script. For a single leaf, the root is equal to the leaf and the tree has a depth of 0 additional layers. Two leaves require a depth of 1.

Depth 0 control block:

  * Length of control block: 1WU
  * Header byte (script version, sign of output key): 1WU
  * Inner key of root key: 32WU
= 34WU

Depth 1 control block:

  * Length of control block: 1WU
  * Header byte: 1WU
  * Inner key of root key: 32WU
  * Hashing partner in tree: 32WU
= 66WU

Script path spending cost in addition to key path spending cost

Script path spend assuming 2-of-2 MuSig leaf

* script size: 1WU
* script "<pk> OP_CHECKSIG": 33+1WU
* Depth 1 Control block: 66WU

57.5+(1+34+66)/4 = 82.75vB

Leafs cannot do MuSig, construction with 2-of-2 OP_CHECKSIG:

* +2nd sig: 1+64WU
* script size: 1WU
* Script "<pk1> OP_CHECKSIGVERIFY <pk2> OP_CHECKSIG": 33+1+33+1=68WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+68+1+1+32+32)/4 = 107.5vB

Discarded other variants

Less efficient construction for 2-of-2 OP_CHECKSIG

* +2nd sig: 1+64WU
* Length of script: 1WU
* Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+1+1=70WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+70+66)/4 = 108vB

Less private, more costly variant with a single 2-of-3 leaf in lieu of two 2-of-2 leaves:

* +2nd sig: 1+64WU
* +1 empty witness item: 2WU
* Length of script: 1WU
* Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+33+1+2=104WU
* Depth 0 Control block:

57.5+(1+64+2+1+104+1+1+32)/4 = 109vB

Disclaimer: All data best effort, don't trust, verify. Also, please correct me, if I made a mistake somewhere.


Is mastercoin a perpetual bitcoin machine

No.
Mastercoin clients form a bridge between the bitcoin network and the mastercoin network riding on top of it.
When Alice sends Bob one bitcoin in exchange for, say, 2 Mastercoins, the Mastercoin client recognizes a standard bitcoin transaction from Alice to Bob and a mastercoin transaction (encoded as a negligible amount bitcoin transaction) from Bob to Alice.
No bitcoins are created.

This type of transaction is the basic way to create value in the mastercoin network.
Note that the same answer doesn't hold for other currencies, say US dollars, because there is no direct way for the mastercoin client to know that US dollars changed hands.


You can parse blockchain only once and save all utxo into database. I am not sure that it is best way because I do not know the target of your efforts


Multiple spending transactions from a single Bitcoin address?

Assuming that by "validate" you mean "confirm" then a chain of 100 transactions sent from the same wallet should, theoretically, all confirm in the next block or two - assuming that each transaction's included fee is sufficient.

However, the outcome described above is only theoretical, because many clients place a relay limit on unconfirmed transactions in a single chain. The Core client, for example, does not accept more than 24 unconfirmed transactions from a single chain into its mempool.

In the case of your example chain of 100 transactions there could, therefore, be a best-outcome delay of at least 5 blocks before all the transactions are confirmed.

Further to your question, it is not a case that the 100th transaction is dependent on the 1st or the 99th transaction to have to confirm first. If each of the simultaneous 100 transactions being sent from a wallet is valid and has sufficient fees, then they will each be mined as individual valid transactions by miners, regardless of their wallet of origin. If a miner happens to be running the Core client, then there will be a batch limit of 24 transactions (from the single chain) that can be mined per block.

As pointed out in the comments, a transaction can have more than one output, so your example's 100 recipients can each be sent bitcoin via a single transaction.


Pushing a large signed transaction (testnet) using Python

Isn't it possible to switch pybitcointools to another service?

Try http://webbtc.com/api/relay The API should be similar (I haven't tested both)

It is also possible to check tx for validity (by send attempt) here: http://webbtc.com/relay_tx

(There are testnet API there, my links are for mainnet)


What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?

The theory
It is assumed that in order to forge an ECDSA signature you need to compute the private key for a given public key first (this operation is known as the "discrete logarithm" (DL), and its hardness is the basis for ECDSA's security). In order to do so, you must actually have the public key.
Once you have the public key, it is assumed that you need at least 2128 operations to compute its private key. That's an enormous amount (if every computer in the world could do one relevant operation per clock cycle it would take over 100 million years; in reality it'd be orders of magnitude more than that). However, that is assuming that there are no fundamental breakthroughs in algorithms to compute the discrete logarithm, or quantum computers. A sufficiently powerful quantum computer (not anything anywhere near what already exists) may be able to do this computation much faster.
By using an address that contains a hash of the public key rather than the public key directly, the actual public key is not revealed to the world until the output is spent by its owner. Barring any (spectacular) vulnerabilities found in the used hash functions (SHA256 and RIPEMD160), even a quantum computer cannot trivially find a public key from a hash function. However, the 160-bit hashes used are still considered relatively weak in this case (280 operations on a sufficiently powerful quantum computer).
In short: the argument is that by using public key hashes, the ability for someone with a DL break, or a hypothetical quantum computer, to steal coins is made harder.
In practice
What I write in this section is my own opinion, and presumably not everyone agrees with it.
I believe this (often repeated) advantage of hashed public keys is marginal at best, and a false sense of security at worst. There are several reasons for this:

The argument only applies until the output is (attempted to be) spent. Once someone tries to spend a pay-to-pubkey-hash output, they reveal the full public key. With minor cooperation from miners, the original transaction could be delayed temporarily to give the hypothetical quantum computing attacker time to find the private key and steal the coins.
Address reuse was, and still is, very common, and apparently hard to avoid. Whenever addresses are reused, their public key is revealed on the first spend, making all future ones vulnerable still.
Almost all interesting things that people do with Bitcoin (including multisig, 2FA, escrows, payment channels, BIP32 accounts, ...) involve sharing public keys with other parties. It's an illusion to think that in such a world any security is gained by using public key hashes - as public keys are revealed all the time still, often without people even knowing about it.
Even if you restrict yourself to carefully not rely on any of these techniques and keep all your public keys actually secret until spent, there are over 5 million BTC (my own research) stored with publicly known public keys. I cannot imagine that BTC retains any value if those become practically vulnerable to theft (or even just credibly believed to be vulnerable).

This doesn't mean we have a problem. Sufficiently powerful quantum computers are far away - if they're feasible at all for the enormous number of q-bits needed to solve these problems. This gives us time to slowly migrate to schemes that are actually quantum resistant (by not using ECDSA or similar cryptography at all). This is not yet done, as currently existing quantum-resistant schemes come with very large keys and signatures, and various other caveats. This makes them very unappealing fow now, but research on them is proceeding rapidly, and, if needed, they exist.
Should you use public key addresses?

If one was writing a cryptocurrency would you advise against the addresses being the public key encoded in base58 with a checksum on the end? why?

Advice on other cryptocurrencies is off-topic here, but the Taproot proposal for Bitcoin would effectively do this. Its outputs (and thus addresses) contain a full public key, because it comes with numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier).
The Bech32 address format is used for these types of outputs, which has a number of advantages over Base58 (easier to transliterate/compare, stronger error detection, more extensible, smaller QR codes, ...).
Disclaimer: I'm a co-author of both the Taproot proposal and the Bech32 standard.
TL;DR: public keys should be public.


You most likely mistyped one or several words.
Manually trying different combinations can be a tedius process.
If I were you, I would be using seed recovery tool like btcrecover.

Are you familiar with the Levenshtein distance? The word(s) you misstyped are most probably the one(s) with shortest Levenshtein distance to the BIP32 spec words.

Example:

  staff can easily be mistaken for stuff or vice versa, since both are BIP32
  words.


Why can a 51% attacker not change the block reward?

Even you have 51% of hashpower you can not change the software on other computers to accept your blocks.


Javascript has access to OpenGL ES, including shaders, so it has access to programmable parts of the GPU at nearly native speeds. I think that a smart kid might be able to build a fragment shader that does SHA256 hashing, which outputs to the stencil buffer, so that Javascript has a 2-way communication channel with the GPU.

So yeah, you could probably use javascript to mine at really nice speeds. Maybe 70% or 80% of what an OpenCL GPU miner does?

[Edit] oh look, someone already built a fragment shader that does that
[Edit 2] and an actual JS/WebGL application


Who is the certification authority in Bitcoin?

Depending on what function of the certification authority you are looking for, Bitcoin doesn't need one, or the blockchain does it.

Identity in e-banking vs identity in Bitcoin network

Electronic banking relies on the communication between bank and customer being secure which is what they use encrypted protocols for. They don't use either hashing, nor private and public keys in any similar fashion as Bitcoin. Actually, when you order a payment through e-banking, you have to reveal all the secrets to the bank to authenticate yourself: E.g. you put in your user name, your password, and then a specific one-time code as requested by the bank, or when using a credit-card, you give name, credit card number and security code. As these pieces of information would be sufficient to hijack the payment in a man in the middle attack, communication needs to be secure and encrypted. To that end, a certification authority gives out "passports" that allow you to make sure you're talking to the right entity.

On the other hand, communication in Bitcoin is authenticated by the content of the message itself. When you order a payment, it includes a signature that could only have been created by the owner of the address that held the money previously. Nobody can change the message, because the signature would be invalid for any other message, and they cannot produce another valid signature without having access to the private key. The secret is not revealed to order the payment. Therefore, it is not necessary to encrypt communication within the network, and also there is no need to certify the identity of network participants. One can tell directly from the message whether it is valid or not, making the identity of the source of the message irrelevant.

Authenticity of payments in e-banking vs Bitcoin network

In e-banking only the bank and you know your balance. Therefore, when you order a payment, the bank will check their ledger and confirm the payment.

In Bitcoin, everyone can check whether a balance is available to be spent. As explained above the transaction order itself can be checked for validity by every participant, so it is impossible to spend money that isn't yours. The blockchain keeps track of the balances, therefore becoming the ledger everyone referring to when checking payments. Yet, the blockchain is extended in a decentral process, so while the blockchain is central to the network, it is maintained decentrally.

Where e-banking and Bitcoin are similar

The one thing that still can be attacked in the same way in Bitcoin as in e-banking is the other side of the payment: People can try to fool you into paying something that you didn't intend to pay for. You still need to figure out where to send money. That's where Banking and Bitcoin have the same vulnerability to phishing sites. In fact, Bitcoin is a bit at a loss there, because once you've sent the money it's gone, while you may have a recourse through your bank by having them reverse the payment.


Exporting Private Keys for wallet in Multibit

Yes, you can. The private keys unlock your wallet, which will be synchronised to the network. You then have access to the wallet, with the bitcoins before and after the back-up of the private keys, just the balance blockchain.info says you have. So no need to have an recent back-up of those keys.


Could the "pizza guy" sue now had he not received the pizza?

No, he wouldn't be able to sue.

Basically the Statute of limitations for scam is 5 years, after this delay the claim can be dropped in court.

Even if he still went for it, he would only be entitled to the USD value of the transaction at that moment. It would be unreasonable to ask for a refund 10000x the price that was paid, see I paid in bitcoin, now I'm owed a refund. Can I demand it in bitcoin too?


Unspendable outputs vs Black Hole address

If that is the case, what is the need of a black hole address like the bitcoin eater? Couldn't bitcoins be provably "destroyed" simply using such an unspendable script transaction output?

There is no need for addresses like the Bitcoin eater, but it is far easier to send Bitcoin to burn addresses than it is to create provably unspendable outputs. This is because most wallet software do not have the functionality to create outputs that are not P2PKH or P2SH, so it is more difficult to create the provably unspendable outputs.

However if you do want to burn some coins, you should use provably unspendable outputs as these do not bloat he UTXO set and there is not a no possibility that someone can get those coins (the burn addresses technically have a private key so someone could in theory get those coins by figuring out the private key).


Why was Bitcoin Core in need of a fork of LevelDB?

Sometimes LevelDB has bugs and those bugs sometimes are not fixed in a timely manner in the upstream LevelDB project. These bugs can be problematic for Bitcoin Core so a fork of LevelDB was created to handle these bugs specifically.

Additionally, to ensure security, we want to use a specific version of LevelDB at a specific commit. By having our own fork of it, we can control what version and what commit it is on so that we can control exactly what code we are putting into Bitcoin Core.


Are timestamps in transactions trustable?

Transactions do not have timestamps, so the timestamp that blockchain.info displays is whatever time their node received the transaction. The time shown will also change to the time that it was included in a block. In general, it is not reliable to trust the timestamp given for an unconfirmed transaction on blockchain.info as it is entirely dependent on their node.


bitcoin-qt keeps on quitting with "failed to read block"

Start bitcoin-qt in a new command prompt with the flag -reindex after you make sure your 3G provider doesn't block your downloads after a certain threshold.


How to Retrieve BTC without syncing wallet

You may want to enter your address into one of the many blockchain "services" webpages, for example: https://blockchain.info/

On the top right you can enter an address, and see if you have a balanceon your address...


You are likely running into power limits. Your USB hubs must be powered properly, able to supply the full current all of these devices need to operate.


Can't Make Sense of Why OP_CHECKSIG Fails Here

OP_CHECKSIG needs to have the whole transaction to hash and to verify the tx. Btcdeb has the feature of allowing the tx as an argument however the website you linked doesn't hence this opcode is doomed to fail every time on this website.
It is reasonable to expect supplying the signature to verify the script/tx because otherwise to steal his coins, I would be able to copy one of his signatures and put them in my transactions.
Therefore I do suggest downloading and using the complete btcdeb.


Yes Coinbase has not mentioned supporting Bitcoin Gold or Not so to be safe definitely move your BTC to a wallet so you have control of your private keys.

On Oct 25th the fork will happen and on November 1st you will be able to access your BTG Bitcoin Gold by using your private keys.

Here is a video explaining this better...
https://www.youtube.com/watch?v=natH7Chtv40

Here is the Bitcoin Gold Web site: http://btcgpu.org/


History of cold boot attacks on Proof-of-Stake miners

It's not an appreciable issue. If somebody has physical access to a a miners server rack, it's game over no matter what "memory encryption" is used. As for the attack specifically, I doubt it's ever been used outside of security demonstrations and high level infiltration rather than something as completely insignificant as Bitcoin mining.


The relevant source is this:

if (AllowFree(dPriority)) // at least medium
{
    if      (AllowFree(dPriority / 1000000))  return tr("highest");
    else if (AllowFree(dPriority / 100000))   return tr("higher");
    else if (AllowFree(dPriority / 10000))    return tr("high");
    else if (AllowFree(dPriority / 1000))     return tr("medium-high");
    else                                      return tr("medium");
}

The label only changes to something higher than "medium" when the priority is at least 1000 times larger than the minimum. Your priority is large (I estimate 570/144 * 27 = 107 times the minimum), but it's not that large.


The major difference is, while Hawala means trust, Bitcoin does not depend on trust. Everything is made of cryptographical signatures, making it 100%** safe, while Hawala cannot / may not be trusted.

** Two exceptions: 1) Majority of hashrate is attacking the network. See this 2) The theoretically possible, but practically impossible hash collisions. It doesn't happens, while the theoretical safety isn't 100%, rather 99.999999999...%


Google's Sycamore processor has parallel-processed 2^53 states. Is this a threat to Bitcoin?

First of all, it's important to note that Google's Sycamore has not (yet) processed any quantum algorithm, but instead has just proved that the quantum processor is capable of maintain quantum effects on all 53 qubits during operations. This is important because there's still controversy on if all quantum computers built to date exhibit real quantum advantages.

In order for this processor to become a "practical" quantum computer, also measurement physical errors must be lowered.

Also, to make computations that can actually break current cryptography algorithms, the number of qubits must probably be raised, to around 1000 or more, all depending on how low the error rate will be.

And answering the second question, no, this result is in line with prospections on quantum computing, so the (optimistic) estimations of around as early as 2027-2040 to break ECDS still maintain. But all depends on current trends that nobody knows if can be maintained or not, as this is all based on cutting-edge engineering and mathematical advances.

Also note the link indicated by @ugam-kamat regarding practical mathematical implementation of cryptography breaking algorithms that also points to a minimum of around a thousand usable qubits to break nowadays signatures. This would also raise the real number of needed qubits by some factor n>1 (n>>1?), as the previous noted increment was due to measurements errors which would still apply as the number of qubits raises.


What are the differences and similarities among Paymium, Bitpay, Coinbase, etc.?

Paymium, operates Bitcoin-Central.net market exchange.  That exchange has partnered with a financial organization such that your EUR balance held at the exchange will be (once they go live with that) guaranteed by the government.  They will only be doing BTC/EUR when this goes live.  Currently they offer BTC/USD, BTC/GBP and BTC/EUR markets but no fiat balances are currently guaranteed.

BitPay is a payment processor for E-Commerce as well as for bricks and mortar / point-of-sale.  This allows a business to accept bitcoins for payment and the proceeds are delivered to the merchant as directed.  This could be 100% fiat (e.g., all bitcoin sales get converted to USDs immediately, or a mix, .. like 30% USD, 70% BTCs, etc.)   The currently can send payments to merchants in U.S., Mexico, Canada and several nations in Europe.

Coinbase account holders get a secure web-based bitcoin wallet, and by linking a U.S. bank account, the ability to buy/sell bitcoins directly from/to Coinbase at a USD conversion rate that is very close to the last price quoted from London based bitcoin exchange Bitstamp. Coinbase itself is not a crypto-currency exchange. Coinbase also offers bitcoin transaction processing services to merchants.

There are quite a few exchanges.  The bitcoin.it Wiki has Buying bitcoins and Selling bitcoins indexes that are fairly comprehensive as to the options available.


What prevents a pool miner from stealing an entire block?

When you are running a miner in a pool, you communicate through getwork protocol. It basically boils down to requesting work and sending back shares (and in rare cases, solutions to blocks). Work in getwork is a Block Header, not an entire Block. The coinbase transaction is encoded in the merkle root, but is not known to the miner. The block hash that creates a share or a block solution is ONLY valid for a given merkle root. If you change the coinbase, giving yourself all the money, you invalidate your solution and have to start over. If you are mining your own blocks, no pool should accept your shares (unless it is dumb).

To sum up - a miner does not know the coinbase transaction, nor can it change the block without invalidating it.

On the other hand, a miner can withhold a block solution while still submitting other shares. This will make the pool get less money while still having to potentially pay for those shares. This exploit can be detected by statistics though, so over a long period of time such a malicious miner can be found out.


When is the earliest we will see SegWit transactions on main net

Nobody can determine the date for that event.

SegWit, like every soft fork, requires a majority of miners to enforce the new rules in addition to economically relevant nodes.

The initial BIP that proposes segWit, BIP 141, requires 95% of miners to signal they are ready for 2 weeks, before starting to enforce the new rules. This threshold is set so that at most a small percentage of miners (5%) would end up on another chain, making it unlikely that the minority chain would accidentally being longer, and thus confuse light clients.

Due to various political reasons, this signalling for BIP 141 readiness has not happened. Various new proposals have been made to help move this process forward, including BIP 148, BIP 149, and BIP 91. BIP 148 and BIP 91 are meta-approaches that make certain demands on signalling for the original BIP 141. BIP 149 proposal a completely new SegWit deployment, independent from BIP 141.

At the time of writing, the earliest time at which 95% for BIP 141 could be reached is around August 10th 2017. BIP 141 specifies another safety period of two weeks after that before the new rules take effect, which would be around August 24th 2017. BIP 91 and BIP 148 do not change this, as all they do is force signalling for BIP 141.


Mining generates block and the generation of block is rewarded with 25 bit-coins? So from where bit- coin is mined?

The new bitcoins are generated as a special transaction called a Coinbase transaction, which is the very first transaction in a block. That transaction has special inputs that don't spend previous transactions, so the bitcoins are completely new. The miners create this transaction when they create a block to be mined, paying the block reward to themselves. Thus if they are the successful miners of the block, the transaction pays them and they receive the block reward.

Note that the block reward is currently 12.5 BTC per block not 25, as of the reward halving on 2016-07-09.


Both BFL hardware and software are quite unstable, and depend on the starting temperature of the BFL hardware.

What you can do is: stop the mining software, power off the BFL miner, and stick the BFL miner in the freezer for 5-10 minutes (or longer, say 1-2 hours) so that it can cool down.

When I got my 50GH/s, it could only run at around 25GH/s. Eventually, I found out that it is temperature sensitive. I have, once in a while, powered it down, put it in the freezer, and then powered it back up.

I get pretty impressive results that way. From an original of 8 out of 16 chips working, I now get 15 out of 16 chips working.


What to do when funded channel node disappears

Generally your lightning node will be able to tell which peers are online (in clightning with listpeers command)

If the other node is offline you can force close the channel by publishing your channel state.. Since the other node has signed your commitment tx as part of the protocol there is no need for it to be online or to help closing the channel.


Error transferring bitcoins to another wallet

This is unrelated to Bitcoin itself. Bitpanda has a minimum withdrawal amount, and it seems that you do not have at least that amount to withdraw. The amount seems to be the equivalent of 100 USD (specifically, it is 0.002167 BTC at time of writing).
If you do in fact have more funds in your account than that amount, I would advise contacting Bitpanda for support.


Anonymity is part of the Bitcoin culture. It was created to circumvent the powers at be, and anonymity plays into that idea quite well.

However the nature of the block chain is that every transaction is totally traceable. You can look at the block chain and determine where every bitcoin has ever been. This seems to contradice most peoples conception of bitcoin as being an anonymous currency.

In some ways it is. If you mine your own bitcoins and generate your own wallet then, even if I can see every transaction, that particular bitcoin or wallet made, I can not know who is responsible for making it.

But in the new age of bitcoin, where the average user does not know anything about encryption, and contracts third party services such as mt. gox to manage their bitcoins for them, anonymity is lost.


off-chain payment channels: Do we need to trust "Payment Service Providers"?

In lightning network payments are onion routed.  The only thing a PSV could reveal is the previous and next hop, but they can not know the origin or the destination.  They know it came from Alice, and went to Bob, but they do not know where Alice may have gotten it from, or where Bob may send it to.


How do addresses that refer to a web site work?

You can add a tag to your address here https://blockchain.info/tags

It will be shown on bc.i site


How do I buy bitcoins using a prepaid credit card? [Canada]

Yes, I am Canadian and I have used both these services:

www.cavirtex.com

They can be added as Online Bill Payee at RBC, BMO, Scotia, or TD Bank (takes 1 to 2 days)

and/or

www.canadianbitcoins.com

I never left my seat and Bitcoins were deposited with the hour!

They use TD Canada Trust, and you can add them as a Payee by calling your EasyLine banking, then make an Instant payment to them.


If you are in the US, you can buy it on coinbase.com or https://exchange.gemini.com/

You need to buy some Bitcoins on coinbase, they will automatically increase your limit. I can buy $5000 worth of Bitcoins on Coinbase, and would if I had the money.

Fees of Gemini are low, ie .05 cents for $20 in BTC, or 50 cents for a $200 order.

Or localbitcoins, if you care about anonymity, but they charge a high markup.


GUIMiner stuck at 99% Done for over 1 hour

Network issues were preventing this from completing.


You can use the wallet passphrase (Bip39 mnemonic) as many times as you like. You don't have to export it again.

But mind, breadwallet does not follow the bip44 chainpath scheme. Importing the passphrase into a different wallet application would first require to "convert the keypath" with a tool.

But i would recommend to not use the same wallet passphrase (bip39 mnemonic) on multiple devices simultaneous! You might reuse addresses and run into a chance of creating double spends.


Do I need to develop a separate blockchain for my altcoin (cloned on BTC)?

Do I need to develop a separate blockchain or it will use the blockchain of BTC / LTC?

That's up to you, you could fork those, BCC is an example of a forked but separate currency. Alternatively, you can start a fresh blockchain.

  Do I need to construct a wallet or it will be created once I compile the code?

"A" wallet? you need many wallets, your users will need to create wallets and not by compiling code. This question makes it sound like this is your first foray into cryptocurrency? If so this is not a good first move or a beginner project.

  How would I be able to mine the coins? Where to put the code once the coin is generated

Yeah, I think you need to do more research. This project is not a small undertaking, you should at least have some experience of mining other coins, and using coins.


Would it be possible to overtake the network by running a secluded mining operation for many years?

'Longer' means 'more total work spent'. You're not going to be working harder than all miners put together are you? Then the only way to get some money is to join the existing miners and work with them. And by doing that you coincidentally enlarge the group of 'honest' miners, making it that much harder for someone else to consider your  'evil' plan.


Can I check balance of wallet.dat without downloading the block chain?

I think your question has an underlying misconception. The wallet only contains bitcoins in an abstract sense: In realitas the wallet only stores the private keys that enable you to spend the bitcoin balance that is associated with your addresses. Think of it this way: When you look into your wallet, you only see a number of little boxes. You know that all these boxes are yours, but from the outside all boxes look the same, regardless of what they contain. You can only know how much you have in this boxes, by opening each of the and counting their contents. This "looking into the boxes" step happens by looking up the balances of your addresses in the public ledger (the block chain). The wallet.dat might contain the balance that was last counted when you compared to the blockchain, but can only be updated to the current state when counting the contents of the little boxes again.

So, without downloading the blockchain and having your software calculate your current balance, you could only check "if everything is alright" by looking up specific addresses. If you received your bitcoins in one transaction the balance is associated only with one address and this address could easily be written down or memorized separately from the wallet. You could then proceed to look up the balance of it on a website such as for example http://blockchain.info. This can be done safely, as the address alone does not allow anyone to spend the bitcoins.

So, summing up: Just from the wallet.dat you cannot get an update on the balance without acquiring additional information. You can however check the balance of addresses directly by using publicly available information.


What library or wallet can be used to test segwit transactions on testnet?

bitcoin core supports this

addwitnessaddress "address"

then compose your transaction and send it, you can do it all via RPC calls, so any programming language that can do rpc calls will work (python, php, go, etc. etc)

help addwitnessaddress

addwitnessaddress "address"

Add a witness address for a script (with pubkey or redeemscript known).
It returns the witness script.

Arguments:
1. "address"       (string, required) An address known to the wallet

Result:
"witnessaddress",  (string) The value of the new address (P2SH of witness script).
}


Why does mining / validation of new blocks have to be complicated / time consuming?

If mining was simple I could find a hundred million blocks in the next five seconds.
Would that be helpful? What would we do with all those blocks?
Thinking about these questions should help you answer yours.


Is it possible to use bitcoin as interplanetary money/store of value?

Let's say humans have finally made a successful colony on Mars, how useful would bitcoin be to transfer value between Earth and Mars?

If you're talking about the Bitcoin blockchain in its current form, it will restrict mining to one of both planets.

Bitcoin's assumptions include a block propagation time between miners is negligible compared to the interblock time (10 minutes). We've already seen the effects of a few seconds block propagation time on Earth: miners being forced to build upon each other's work without validating, to avoid orphaning during that time. This incentive encourages centralization, hurts Bitcoin's security (especially for light clients), and makes mining (even) less permissionless to enter.

The distance between Earth and Mars can be up to 401 million km, when they're on opposite sides of the Sun. Following the laws of relativity, it is fundamentally impossible to communicate between them in less than 22 minutes in that case. A propagation time of 22 minutes would utterly destroy any ability to mine on both sides. As there is a delay of 22 minutes before Earth can mine on top of a block created by Mars, or the other way around, but not when a planet mines on top of a block created by itself, you would end up with an almost persistently forked chain between the two. The slower planer would eventually always switch over to that of the faster planet, making the faster planet win far more blocks than proportional to its hashrate. Effectively, the delay between the two planets turns mining into a race rather than a lottery.

  And if it won't work with the current implementation, what would need to be changed in order for btc to be used interplanetary?

The above issue could probably be solved by using a chain with a ~1 week interblock time rather than 10 minutes, to compensate for the larger propagation time.

If we're fine with mining being controlled by one of both planets (effectively giving that planet the arbitrarily censor the other planet's transactions), it would probably work fine.

There are other issues though; another problem is partitioning. Bitcoin strongly relies on peers in the network to be able to communicate without ending up on their own islands of connectivity. There would need to be multiple independent communication links between the two planets to avoid a partition between Earth and Mars. If mining is knowingly on one side, the worst effect of a connectivity failure is just the lack of ability to see confirmations on the other side, though it may take hours (=a few roundtrips) to notice this.


Is it only out of sheer luck that all my "txid"s are unique? How should I handle multi-vout transactions?

Why has none of them ever used more than one vout?

If each of your transactions only sends Bitcoin to one receiver, then there's going to be only one receiver output in each of those transactions. Hence you only see a single vout per txid.
You can create transactions which send to multiple receivers. You should see multiple vouts for those. You can make them by using the sendmany command or by clicking the Add Recipient button in the GUI.

And what happens the day this happens?

Nothing should happen except that you will see multiple txids with different vouts. In the end, it all depends on your software and how it is handling that. Since it sounds like you have dealt with the uniqueness constraint correctly, nothing should happen.

Why can't Bitcoin Core just clearly list the human-relevant information instead of exposing internal mechanisms to the "end user"/programmer?

If you want human relevant information, use the GUI. The RPC interface is intended for developers and advanced users. The whole point of the RPC is to allow people to build software that use Bitcoin Core and they are going to need to understand and access all of this additional information.


I want to change 0.25 dollar cents in bitcoin for my digital content, is it too little?

currently that's not feasible with bitcoin due to its price. The alternative is to use another coin with a lower price to make it truly a "micro-transaction" with sub-penny fees. But the problem with scenario is your users will now have to buy that coin just to buy your product. Check coinmarketcap.com for a list of coins to use.


Convert EC PRIVATE KEY from .pem into WIF

How can i convert this (preferably using bash/Perl/python) into a WIF that can be imported into (preferably) Electrum?

OpenSSL .pem files contain base-64 encoding of the values encoded using DER. In case of private keys they use PKCS#8 explained in RFC5208. To extract the key itself, you first have to decode the base-64 string and get the key out by reading the DER encoding (the posted example is missing 1 byte since the sequence length is 0x74 but the remaining bytes that come after it is 0x73 bytes). If you want to use OpenSSL itself, try using this command:

openssl pkey -in priv.pem -out priv.key

This should give you the key bytes. Now you have to convert them to WIF (base-58 with checksum). Use your favorite bitcoin library (I don't have any python suggestion but there are many you could find on GitHub) that has byte-to-Wif functions.

  What does this mean? Wallet import format does not say anything about typing

Your one private key gives you one public key that could be used in both compressed and uncompressed form in many different output scripts which then you will see as a different type of address (P2PKH script -> address starting with 1; P2WPKH script -> address starting with bc1; ...). So when the private key is imported in a wallet, the wallet either has to look for all the output script types (like what Bitcoin-Core does) or ask the user to explicitly include the script type (which is what Electrum does).
In other words when you import a private key in Electrum with p2pkh:<key> the wallet only checks the address starting with 1 (legacy or base58) and when import it with p2wpkh:<key> it only checks the address starting with bc1 (native SegWit or bech32) and so on.

As a side note, there is BIP-0178 that proposed extending WIFs to address this and also Electrum briefly used a different way similar to this BIP but stopped because of incompatibility with other clients.


Multisig (2 of 3) BCH, one signed before fork, one after

You cannot simply rebroadcast a bitcoin transaction on the bcash chain, due to replay protection. You need to sign the transaction using the SIGHASH_FORKID as the error message says, which means you will need to use a BCH wallet to resign the transaction


Does this FinCEN Document mean the Bitcoin Network is a bank?

As the document predates Bitcoin, it does not specifically address the Bitcoin network. While the document may apply according to the phrasing, I am not sure whether the Bitcoin network as such is a legal entity as it does not have any formal structure. I would assume that only participants in the Bitcoin network could be addressed by law, i.e. "a company", "an organization" or "a user", much like laws could be passed concerning "anyone spending more than $100 in cash in one transaction", but not "the group of people that get out of bed with their left foot first".

Concerning participants in the Bitcoin network though, according to CoinDesk Bitcoin miners and investors are not money transmitters. Specifically, CoinDesk quotes there

  “The first ruling states that, to the extent a user creates or “mines” a convertible virtual currency solely for a user’s own purposes, the user is not a money transmitter under the BSA. The second states that a company purchasing and selling convertible virtual currency as an investment exclusively for the company’s benefit is not a money transmitter,” the release states.

So, as far as I understand, regular users, miners, and investing companies neither have to register, nor implement the measures listed in the question, while I'd assume that online wallet services and Bitcoin exchanges have to do so.

IANAL, this is not legal advise.


Does Dojima (trading platform) have access to my funds?

Yes it could do that. Luckily, it is open source, so people can check the code to ensure Dojima will not secretly send funds away.

If Dojima connects to Bitstamp for you, it will use the username and password of your account on Bitstamp. This will allow all functionality offered by the Bitstamp API, which includes sending bitcoins to an address.

You will receive an email to verify the transaction, before it is initiated by Bitstamp. This is a security setting you can adjust in your account:
https://www.bitstamp.net/account/security/email-confirmations/

Let's hope Bitstamp will issue API keys shortly, which you can set to "trade only" for example. That would prevent you from having to enter your password in third party applications.

Update 2013-09-23: Bitstamp added API keys https://bitcointalk.org/index.php?topic=38711.msg3218202#msg3218202


bitaddress.org paper wallet vs. single wallet

bitaddress.org does not use the same private keys for paper wallet generation as for the single wallet. It uses the same initial entropy that you provide, but new private keys are generated for the paper wallet. Thus the addresses are different.


How do Bitcoin balances work when an address is controlled by multiple parties together?

Bitcoin balances conceptually are not like bank account balances, but more akin to banknotes: uniquely identifiable, good for a specific amount, and can only be spent in full. The "account balance" shown by your wallet is simply the sum of funds that the wallet knows how to spend. In the case of your multisig example, if user1, user2, and user3 each have their own wallet but each wallet keeps tracks of the multisig unspent transaction output (utxo) as its own, they would each see it as part of their balance.
Basically, it's up to the users to decide how to interpret the spendability of their shared funds. The network would enforce that they would only be able to spend the UTXO once in total, though. Alternatively, it's possible that they share one "watch-only" wallet to track the balance, but each hold their own separate key. In that case this shared watch-only wallet would track the balance only once, but they'd each hold their own key independently.
So, concretely, the users' balances after the transaction from user4 would be:
user1, pubkey1, 1.1 BTC
user2, pubkey2, 1.2 BTC
user3, pubkey3, 1.3 BTC
user4, pubkey4, 1.0 BTC
{user1,user2,user3}, 2-of-{pk1,pk2,pk3}, 0.4 BTC

Where the last UTXO is controlled by the multi-party address as described and has different spending properties than the individual balances of the the users.


how the miner start to count the timestamp to insert in the block

The timestamp is set by the miner and is part of the data hashed for the Proof of Work. So it is set at the time the miner begins hashing a particular header and searching for a nonce for it.


How do I fund BTC-e and transfer money there instantly from other exchanges?

Currently there is no such option, hence the difference in price you see. Bitinstant used to offer the service I believe, but now it's only offered as a withdrawal option.


When we buy/ sell bitcoin through some exchange ... what is the process

The answer to your question is number 3.

  Exchange itself is a node in the network and to which i am communicating and it is broadcasting my transaction in the network

  why my balance gets updates instantly in exchange?

Some currency exchanges (and BTMs) just send your BTC to whatever Bitcoin-address you give them. This is subject to the usual Bitcoin block production timing. If the exchange subsequently goes bust you lose nothing.

Other exchanges act like a bank, rather ironically. They insist you open an account with them and just change a number in your account without actually performing any Bitcoin transactions. The number shown as the balance in your account basically says that is the amount they owe you (not the amount you own as far as the Bitcoin network is concerned). This is arguably the most risky way to hold Bitcoin (other than for someone who trades currencies several times a day). If the exchange subsequently goes bust you lose everything.

As the wise folk say: "No Private Key - No Bitcoin".

  how can be ensure we are not duped by second type of exchange?

There is no infallible way to ensure you are not duped by the second type of exchange (or by criminals hacking that exchange). Such exchanges are inherently absurdly risky. Remember MtGox, MyBitcoin, Bitcoinica, Neo & Bee, Bitinstant, NiceHash, Moolah, Cryptsy etc. Peruse this website

Don't just assume that a unique string they shared with you is a private-key. Verify that it is by importing it into a standalone wallet and checking the balance (then delete the wallet and clean unused space on the hard disk or Flash memory)

The only sensible action, if you plan on keeping Bitcoin for more than a day or so, is to immediately transfer "your" bitcoin into a paper-wallet (which you generated privately, not generated through some online website) or into a hardware-wallet (directly purchased from the manufacturer) that only you control and which no-one else has ever touched or seen.

If you need to constantly see your Bitcoin balance, set up a watch-only wallet. That way your private-keys are never exposed to the thousands of fanatically determined criminal hackers roaming the Internet.

Related:

Do you 'own' Bitcoins purchased via an exchange?
Pros and cons of using Mt. Gox as an e-wallet
Why is the disappearance of Mt Gox a problem?
Am I scamed? FA exchange trading company is fraud? They are requesting taxes
Is Binance a scam exchange/wallet?
etc, ad nauseam.


How much Bitcoin will I mine right now with hardware X?

Go to http://bitminter.com/test and click the "test start" button. If you have Java installed the miner should launch. Click "engine start" on your GPU(s) to start mining and the GUI will show how many bitcoins per day you will make (on average).

Note that you are actively mining in a pool without getting paid. This test page launches a version of the miner which is only meant to be used for a short time for testing.

Update for 2015: CPU and GPU mining are both long dead. When you buy ASIC mining hardware you will know its hashrate before you buy. Don't buy if you don't. Google "bitcoin mining calculator", input your hashrate, and it will tell you how much you can earn right now, on average. Note that the difficulty will change in the future so your earnings will not stay the same. Also note that with most pools actual earnings vary with luck. Finally, avoid the typical newbie mistake of confusing TH/s and GH/s. 1 TH/s = 1000 GH/s.


Bitcoin core: connect to specific peers from file

Within the data directory for your coin (/dir/for/yourcoin/.yourcoin) you will have a configuration file. Within this configuration file, you will want to place the line connect=IP ADDRESS:PORT

This will make your client automatically attempt to establish a connection with the node(s) you specify.

Example: within myaltcoin.conf place the line connect=192.168.49.50:9332
Obviously just substitute your desired IP address and port.


Bitcoin address generation and UTXO scanning

How much UTXO each address should have to consider generating new address to avoid address re-using?

Preventing address re-use by itself means that an address should not be used more than once. So unless, someone sends you two outputs to the same address in the same transaction (highly unlikely) you are going to end up with one UTXO per address. Preventing address re-use helps your privacy. For example, say you used an address to receive funds from your customer. If you use the same address again, these customers can actually scan the blockchain to see how much amount you have received from others. Not re-using addresses more than once helps protect your privacy.

  When new address generated, from my understanding , I've to scan following address for each address derivation path to see if each index have fund or not?

Depends on what address format are you using for your payment gateway. If you have always generated bech32 addresses, you need not scan the blockchain for P2PKH addresses to see the amount received from your customers. You only need to scan the blockchain for the addresses that you have generated (receiving or change).


how can i query utxo to bitcoind(using bitcoin-cli) with public-private key not wallet

You do not need the uxto of the other address to be able to send it BTC. You just need the address.

If you want to list unspents of an address you don't have the keys for, I don't think bitcoind can help you. However, you can use explorers like blockchain.info: https://blockchain.info/unspent?active=35QEobWVUKjMY2HwKATYYQXRGzXJvdXQCy&format=html (there's also JSON if you want it).


Configure esplora to point to the bitcoind servers ip address

esplora is just the web ui frontend, you also need to setup the (forked) electrs backend for indexing and for providing the HTTP API that esplora queries.
electrs can index the bitcoin block chain using two methods: by reading the blk files directly out of disk, or by querying for blocks using the bitcoind rpc. The first method is significantly faster, but requires electrs to have filesystem access to the bitcoin datadir, which would typically mean running them on the same server (you could technically do this remotely but you'll lose most of the performance gain, so not much point in doing that). The second method can work if you have two separate servers, but I wouldn't recommend it (would be painfully slow).
To setup electrs, install Rust and:
$ sudo apt install clang cmake # required for building rust-rocksdb
$ git clone https://github.com/blockstream/electrs && cd electrs
$ git checkout new-index
$ cargo run --release --bin electrs -- -vvv --daemon-dir ~/.bitcoin

If the bitcoin datadir is not at ~/.bitcoin, change --daemon-dir to point to it. It should automatically pick up the rpc credentials from the cookie file. If you want to index from a remote bitcoind node, set --jsonrpc-import --daemon-rpc-addr <addr:port> --cookie <user:pass>.
By default, electrs will bind its HTTP API server on 127.0.0.1:3000. To enable remote access, it is recommended to setup a reverse proxy with tls (like nginx) in front of electrs. You could also set --http-addr <host:ip> to have electrs accept remote connections directly, but you probably shouldn't.
The initial indexing process will take quite some time and disk space (up to 1TB at the peak during the indexing, which then shrinks down to about 450GB after compaction). To test it worked, you can try issuing requests to the electrs HTTP API:
$ curl http://localhost:3000/blocks/tip/height
$ curl http://localhost:3000/address/1EMBaSSyxMQPV2fmUsdB7mMfMoocgfiMNw

Then, to start esplora and point it to your electrs server, install nodejs and:
$ git clone https://github.com/Blockstream/esplora && cd esplora
$ npm install

# needs to be set to the URL where the electrs HTTP API is available for
# requests coming from the user's browser. if you're browsing from the same
# machine running electrs, this should work:
$ export API_URL=http://localhost:3000/

# start a dev server on port 5000 (on-the-fly babel/browserify transpilation, slow, cpu hog)
$ npm run dev-server

# or pre-build the web ui as a static directory with:
$ npm run dist

You will then have the esplora web ui available at http://localhost:5000/. As with electrs, it is recommend to setup a tls-enabled frontend http server for remote access, either reverse proxying the dev server, or (more ideally) directly serving the pre-built static files.
The last thing that you'll need to do is configure electrs to accept cross-origin requests from the esplora web ui. Do to this, add --cors <origin> to the end of the cargo run command. If you're accessing esplora locally, --cors http://localhost:5000 should work. Otherwise, set it to the origin that the esplora web ui is served from. Or just use --cors '*' if you're okay allowing cors requests from all origins.
Alternatively, you could also use the esplora docker image that makes setting up everything (bitcoind+electrs+esplora) much easier, but that doesn't play nicely with an existing bitcoind node.


What is the risk of using wallet.dat files for long term cold storage?

As long as your machine remains offline and encrypted the files should be usable as long as your hard drive is.

People choose to make multiple forms of backup in part to protect against equipment failure. Paper wallets printed with appropriate paper and ink can last a very long time and can be stores in safety deposit boxes, buried in a hidden location (properly sealed of course) or hidden as words in a poem.

Hardware wallets are another option, but still will require you to store seed words in order to recover in case of equipment failure.


What can a dishonest node do (or try to do)?

just off the top of my head, here are some things a dishonest miner can do:

fail to include one or more transactions in the block. this is not technically 'dishonest', since the protocol does not require that all transmitted transactions be included in the current block. for example it would be considered perfectly ok for a miner to never include a transaction which does not include a mining fee in the current block. however if the transaction does have a fee (the standard behaviour) then a miner can still choose not to include any transaction it likes in a block. to do so would be to deliberately forgo a profit, and so its unlikely, but it is certainly possible. however other miners are unlikely to do the same, so they will include the transaction next time they mine a block.
appropriate unsigned funds for itself. bitcoin scripts are merely puzzles to be solved in order to spend funds. generally puzzles are signed by the sender's private key, but this is not a requirement (though all wallet software does this by default). if someone is silly enough to manually create an output script which does not contain either an OP_CHECKSIG or OP_CHECKMULTISIG opcode then anything in the transaction can be changed by the miner. for example, say someone creates a transaction with output script OP_1 OP_EQUAL then transmits this to a miner to include in the blockchain. the miner can easily complete the puzzle and appropriate these funds by creating another transaction with input script OP_1. (to verify these scripts, just put the txin and the txout in sequence OP_1 OP_1 OP_EQUAL - 1==1). and the most important thing here is that since there is no signature, anybody can modify the output script in the spending transaction, so the miner can direct the funds to the address of a private key it owns.
appropriate any SIGHASH_NONE funds. when signing a transaction, the user's wallet software will put a byte on the end of the signature in the txin script in the spending transaction. an 0x02 byte here corresponds to SIGHASH_NONE which means that all of the output scripts are ignored for the purposes of validation. so if someone sends a transaction like this then a miner can simply put their own address into all the txouts and include that modified transaction in a block, effectively sending funds to itself. however wallet software does not set signatures in this manner so someone would have to be deliberately foolish to loose funds to a miner in this manner.
alter certain transaction hashes via transaction malleability. certain bitcoin transactions are malleable. while a miner is not able to alter the amount of bitcoins you send, or the recipient of these funds, it can modify certain transaction scriptsigs (the txin script) and thereby alter the transaction hash. this occurs because the scriptsig is not signed by the private key. so the miner can alter this scriptsig as long as it does not alter the functionality. note that bip 62 (scheduled for release in bitcoin 0.11) will eliminate transaction malleability for standard scripts, however for certain non-standard scripts malleability will always be a problem. for example if the txout script being spent starts with OP_DROP then any prior stack value (set at the end of the scriptsig) is ignored and so can be altered by a miner without altering the functionality of the transaction. since transaction hashes do include the scriptsig this will alter the transaction hash. any other transactions which were expecting to spend from that hash will be temporarily frustrated and will have to figure out the new hash value to spend from (by following the transaction trail in the blockchain).


What happens to wallet.dat if I uninstall and re-install on Windows Bitcoin desktop client?

Nothing happens to it. None of Bitcoin Core's data (which includes your wallet files, the block files, the block indexes, the chainstate, etc.) is removed when Bitcoin Core is uninstalled. All of this data is stored in a separate location from the installation.


Is there a Drupal shopping cart interface for Bitcoin?

You could have a look at uc_bitcoin by Mike Gogulski that seems be what you are looking for. A word of caution though: The GitHub code has not been updated since November 2010, it is for Drupal 6.x (has not been tried on D7) and Mike states that "There’s probably not going to be an update for a long while, either, so fork and code away". Anyway, here's some info about it:

  A Bitcoin payment method for the Ubercart shopping cart for Drupal.

  Features

  Generates a new bitcoin address for every order
  Provides payment address to customer on site at checkout, plus in a
  subsequent email
  Configurable timeout after which unpaid transactions will be
  canceled automatically
  Configurable number of Bitcoin network confirmations after which an
  order is considered paid
  HTTP or HTTPS access to bitcoind

There is also a project by Darrell Duane that is based on Mike's project. There is no download available yet and the project page was updated in June 2011.


How does bitcoin work from a technical computer science cryptography perspective?

Take a look at this Whitepaper by Satoshi Nakamoto: http://bitcoin.org/bitcoin.pdf


What is the algorithm used to sign data within Nxt?


Can bitcoin core verify a third party blockchain download?

If you give Bitcoin Core a fully populated data directory, it will use it without any validation.

However, if you only give it the blocks/ subdirectory, it will fully validate it to recreate the chainstate directory, exactly as if it were received over the network.


How to create the same (2 of 3) multisig adresses as electrum's multisig wallets with createmultisig?

See BIP45.

Electrum is ordering the pubkeys lexicographically, ie

03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed
03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d5
03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a

Note they're all 03, so it's 72=>f5=>f9


Can an altcoin be worth less than 1 satoshi (0.00000001 BTC)?

Yes

  Is this a reasonable position?

No


How does longest chain propagation take place in bitcoin?

An attack that attempts to outpace the mining power of the whole network by itself is called a majority-attack or "51%-attack". Concretely, your example is a doublespend attack by means of a majority attack. When the attacker publishes their chain-tip, each node performs a chain-reorganization to switch to the best chain.
Concretely, the blocks B4 and O1 both share the hash of B3 as their prevHash. Once the attacker announces the blocks O1->O2->O3->O4, other nodes will notice that this chain-tip has more total work, find the last shared ancestor in the blockchain (B3), revert all blocks up to the shared ancestor, and then apply the new blocks to converge on the best chain-tip.
A blockchain-fork and chain reorganization can also happen benignly when two miners happen to find a block at the same moment. At that point the network's nodes are split in opinion what the best chain is, since each node considers the block it first saw to be the correct one. Once another block extends one of the two chain-tips, the network converges on the best chain as the nodes hear about the new block.


Storing Provenance details in Bitcoin Blockchain

Does the bitcoin blockchain allow you to store this document hash (or
  anything else), is it not meant specifically to store the bitcoin
  crypto currency transaction details??

Yes, the Bitcoin blockchain isn't projected to store the data inside it, but it is possible with the type of transaction called Transaction NULL data, and it uses the OPT_RETURN operator of Bitcoin script.

Transaction NULL data (OP_RETUNR)

It was introduced in version Bitcoin Core 0.9 in 2014, this transaction marked the transaction of how not correlated with moving of bitcoins.

The scriptPubKey is simple with OPT_RETURN, the example is like how this:

OPT_RETURN <data>

From documentation of Proof of Existence that I have read quickly say this

  Calculate the document's SHA256 digest.

  Find a transaction in the bitcoin blockchain containing an OP_RETURN output with the document's
  hash prepended by our marker bytes, which are 0x444f4350524f4f46 (or
  'DOCPROOF' in ascii).

  Some online services like Coin Secrets or blockchain.info's list can help you locate OP_RETURN transactions more easily.

  The existence of that transaction in the blockchain proves
  that the document existed at the time the transaction got included
  into a block

So the ScriptPubKey started with this code

OPT_RETURN 0x444f4350524f4f46...

With this method, the System of Proof of Existence can found all transactions generated and the quantity of data stored with the System can be calculated with a simple parsing of blockchain (it can be is a good exercise).

There are other information on Transaction NULL data, like

You can not store a lot data, because exist a limit fixed to 80 bytes.
These transactions are not indicated by Bitcoin core (official Client Bitcoin)
You can read more details on the transaction null data on BitcoinBook

  I would have thought these solutions will use their own blockchain.

It can be is a solution to implement this System, but the develope an own blockchain that work is difficult.
I want to add another information on the implementation of this system, for storing the document is necessary a blockchain system?
I think is a good solution a distributed database because with document there are different problems, like:

The document, an example a certificate can contain some error (This was an problem that happened to me) and if this certificate was stored inside the blockchain is immutable and it can not be invalidated because the base of blockchain is immutability.

But this was only my think.


If you have a secure channel to the recipient or some way to identify communications as coming from the recipient, just have them send their Bitcoin address. If you have no such channel or method, it's obviously impossible. What can you do to prove your address is yours that I can't do to prove my address is yours?


I had exactly the same problem with litecoin 0.15.1 and it helped me to run it with --reindex option on the command line. I only had to do it once...


How can I programmatically know when someone sends me Bitcoins?

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


How to get the Input Address from vin where only a txid is given (Insight-Api)

First, use the API to get the information on the txid.

/api/tx/e3f0e88ce224d342a0189c1b9d2fd488d8bda2f303dbe1e1dbbaa5f51d9f4a53

This result will include all of the details you're looking for. Here are the parts that you're asking about. The n here corresponds to the vout number above, I believe, and the value and addresses values are the input amount and address.

"value": "2405.38864196",
"n": 1,
"scriptPubKey": {
    ...
    "addresses": [
        "1NG1nT2ZuFw47f41mGjYpPp7J837yTQZhB"
    ]
},
...


Crypto Street is a platform launched to do exactly this. We support BTC, LTC and FTC for now. We plan to add additional altcoins as they prove viable or in some way substantial.

(DISCLAIMER: I am one of the owners of the site).


What prevents a miner from stealing inputs when they are still in the working pool ?

Bitcoin uses public key cryptography, so each address has an associated public key, and private key.

A transaction is signed using the private key of the inputs, without knowing the private key, you cannot move coins. So if someone (a miner) wants to change the outputs of your transaction to steal coins, their modified transaction would be rejected due to invalid signatures.

For their attack to be successful, they would need to know your private key, so that they could use it to properly sign a transaction to output addresses that they control.


To see how much BTC you have, you just need to open your wallet up, make sure it is fully synchronised, and then check your balance. If you don't want to wait for it to synchronise, you can copy and paste your addresses into a block explorer to see the balances on there.


How to create a brainwallet with bitcoinjs?

First of all, don't use 1 word seeds, that will be too easy to brute force...

index.js

const bitcoin = require('bitcoinjs-lib')

const brainsrc = 'satoshi'
const hash = bitcoin.crypto.sha256(Buffer.from(brainsrc))
const keyPair = bitcoin.ECPair.fromPrivateKey(hash)
const addr = bitcoin.payments.p2pkh({ pubkey: keyPair.publicKey }).address
const secret = keyPair.toWIF()

console.log('The brain wallet of '+brainsrc+' \nAddress: '+addr,' Private key:'+secret)

output:

$ node index.js
The brain wallet of satoshi
Address: 1xm4vFerV3pSgvBFkyzLgT1Ew3HQYrS1V  Private key:L4XnHhvLC1b4ag9L2PM9kRicQxUoYT1Q36PQ21YtLNkrAdWZNos6

Examples can be found on the git repo: https://github.com/bitcoinjs/bitcoinjs-lib#examples


How can I use Bread on iOS to manage bitcoin and litecoin?

As far as I can tell, Bread doesn't support Litecoin in any way.  It only supports Bitcoin.  So you can use it to manage your Bitcoin if you wish, but you'll need to find a different app for Litecoin.


How to transform a private key into an ECKey?

The valid private key is L48r9sYN2dtsWHWwJ1Xez27W7a3X7RvG6obrmVgU2JLTFQeUCn not L48r9sYN2dtsWHWwJ1Xez27W7a3X7RvG6obrmVgU2JLTFQeUCnkh. You mistyped and added "kh"


Does my client accept inbound connections?

Get your ip from http://whatismyipaddress.com/ and put it in here http://www.subnetonline.com/pages/network-tools/online-port-scanner.php with port 8333. If you can accept incoming connections you should see a result similar to below:


What if I create a new address and I'm given one which clashes (already exists, it is being used by other user)

A bitcoin address is a 20-byte hash of a 64-byte public key (plus an ID and checksum to bring it up to 25 bytes).  As such, there are two theoretical possibilities with a clash:

Two separate people own public keys which hash to the same value
Two separate people own the same public key

Due to the way that Bitcoin transactions work, either of these situations would be enough for one party to spend the funds attached to the address.

So it's worth considering the likelihood of such a scenario.  Let's assume we have 7 billion people on the planet and they all use Bitcoin.  For there to be a 0.00000000001% chance of just two of the total in-use addresses clashing somewhere each person would need to have 4 trillion active addresses.

(Note that this is just calculating the chance of a hash collision; the chance of hitting the same keypair is so much more remote it's not worth bothering with).


Running out of memory, how can I reduce the size of wallet.dat?

Bitcoind uses a lot of virtual memory, due to having multiple threads, and maintaining several node-wide and per-peer caches of data (UTXO cache, mempool, relay cache, network buffers, known invs list, ...).

Until recently, many of these were effectively unbounded, depending on network conditions. The upcoming release of Bitcoin Core 0.12 has far better internal memory accounting, UTXO set limiting, mempool limiting, and more compact internal representations.