What is the difference between secp256k1_ecmult_gen and secp256k1_ecmult?

How should these two functions be used properly?

A simple answer is "not at all". Those functions are not exposed in the public API of libsecp256k1, and that's the reason why they don't have user-targeted documentation. Instead, they're used as internal subroutines, mostly for the implementation of ECDSA and Schnorr signatures.
Be advised that cryptography should be implemented by experts. It's very easy to shoot yourself in the foot if you don't know what you're doing (and in fact, even if you know what you're doing).
Having said this, here's a high-level overview:

secp256k1_ecmult_gen gets as input a scalar a and computes the multiplication aG with the standard generator G. This function is constant-time in the scalar a, i.e., it ensures that the timing of the computation does not leak information about a. That's why it is used whenever the scalar is a secret, e.g., for key generation when computing the public key xG from the secret key x, or for signing when computing the nonce rG from the secret scalar r. In general, the requirement for a constant-time implementation makes makes code slower (for example, you can't have early returns).
secp256k1_ecmult gets as input two scalars a, b and a point P, and it computes aP + bG. This function does not ensure constant-time computations. This computation is exactly what is necessary for signature verification, and the function is suitable because no secret values are involved in verification.
There's also secp256k1_ecmult_const. It gets as input a scalar a and point P, and it computes aP in constant-time. (So in terms of functionality and security, it is a more general variant of secp256k1_ecmult_gen that works with arbitrary points P. As such it is less efficient because it cannot rely on some precomputation techniques that require to know P upfront.) This is used as a subroutine in the ECDH (Diffie-Hellman) module for computing the shared secret in the key exchange.


Increasing the odds when solo mining with low-medium hashrates

No, neither of these things will help.

The only thing that really affects your chances is your hash rate, and the measures you describe do nothing to help it.

One other thing that can make a very slight difference (< 1%) is latency: the time it takes you to receive new blocks from the Internet (or work from your pool), and to send out your own.  In the unlikely event that you find a block very close to the same time as someone else, these would slightly increase the chance that your block is received first by other miners, and thus decrease the chance that it is orphaned.  But if your pool servers are properly run, they should be doing this pretty efficiently already.  Maybe faster than your own full node would be.

The relayfee has no relevance to mining.  If anything, you'd want to increase it, so that you relay fewer transactions and thus save bandwidth for receiving and sending mining work.  But this effect would likely be negligible anyway.


Does mining bitcoin on a laptop have an expected revenue exceeding the cost of electricity and wear and tear on the computer?

No.
The cost of electricity will far exceed the value of the bitcoin you generate. People who are using specialised ASICs in regions with low electricity cost barely break even. Your laptop wil do far, far worse than that.


Can you reset 'used' addresses that were actually never used?

afaik, there isn't.  If the wallets are just for testing, you could remove wallet.dat periodically and start over.  I guess the main reason for doing this would be if you are doing automated testing with tens of thousands to millions of addresses being created and it starts to slow performance significantly.

or you could always hack bitcoind and modify getnewaddress to return the first available address without any balance.  Or create a new API for this.


Is it safe to store bitcoins on p2sh (no multisig)?

Is it safe to store bitcoins in this address with this scriptsig ?

That is actually the scriptPubkey, and it is only safe if you use a safe redeemScript.

A P2SH script is a Pay-to-Script-Hash script, meaning when you spend the coins, you must provide the script (and the hash must match), but this script you provide, called the redeemScript must also succeed when it is executed, and can be any valid script.

Typically this is a script similar (if not exactly the same) as the one you provided, which is a P2PKH or Pay-to-Public-Key-Hash. Thus, it also requires a signature, so if you use a P2SH(P2PKH) it is still just as secure as using a P2PKH because of the signature requirement in the P2PKH, you just have to also provide the redeemScript.


Can anyone initiate a Blockchain transaction into the mining pool?

Nodes store a mempool of valid transactions. An invalid transaction can never be in a block, so invalid transactions never make sense to store or relay around the network. You can make invalid transactions with invalid signatures, but it won’t be accepted by anything.


Which MuSig scheme is optimal? Classic MuSig or this new MuSig-DN scheme?

Firstly, it is worth emphasizing that both classic MuSig (referred to here as "MuSig") and MuSig-DN are relatively new cryptographic schemes and the paper for MuSig-DN is fresh off the presses at the time of writing (September 2020) with no current implementation. So use both at your own risk but even more so for MuSig-DN. The MuSig paper needed to be revised and it is certainly possible that the MuSig-DN paper will need to go through revision(s).
There are so many trade-offs with multisignature schemes that is hard to be precise and weigh them all up against each other. I will outline some of the key trade-offs that Pieter Wuille mentioned on IRC (any mistakes are my own).
Currently, MuSig-DN has a high computational cost with approximately a 1 second signing time on a modern desktop CPU. It is possible that this could be reduced but this would likely impact the existence of a security proof. On computational cost MuSig signing is clearly preferable. (Verification cost is identical.)
The motivation for MuSig-DN in the first place is that it has two communication rounds rather than MuSig's three. On communication rounds MuSig-DN is preferable.
MuSig-DN offers stateless signing which means the signer doesn't need to remember the rounds he/she has already participated in or remember nonces from one round to the next. In contrast MuSig needs randomly generated nonces at signing time and previous state must be stored securely. On stateless signing and randomness requirements MuSig-DN is preferable.
Both MuSig and MuSig-DN have a security proof under similar assumptions.
As you can tell from the above on multiple dimensions MuSig-DN is superior to MuSig. However, the computational cost of MuSig-DN arguably outweighs all the benefits for practical use cases and one would expect classic MuSig to generally be used over the current iteration of MuSig-DN.
As an aside there is a strict improvement of classic MuSig being worked on, let's call it "MuSig2", which has two communication rounds and would allow for private nesting. You could have multiple levels of MuSig aggregation and not tell your sibling participants that you have child participants.
[edit in October 2020: The paper for MuSig2 has now been published.]
For more information on MuSig-DN see this blog post from Jonas Nick and Tim Ruffing.
Thanks to Pieter Wuille for answering my questions on IRC. Any errors are my own.


Is there a visualisation tool for discarded block chains in Bitcoin?

There are several sites that maintain this information, and Bitcoin Core can be asked about it using the getchaintips RPC command.

It is however important to know that such information can never be guaranteed to be complete. Nodes only relay new blocks that are part of the (new) best chain.

A fork appears when two blocks are produced at approximately the same time. They both propagate across the network, and one part of the network sees block A first, and another sees B first. Assuming A eventually wins (is extended first), nodes that saw A first and were not connected to a peer that accepted B first, will never see B.


As a full node, does limiting bitcoind bandwidth hurt the network?

It would seem to me as though every contributing full node would only help the network (regardless of ISP speed). Does limiting the bandwidth of Bitcoin Core actually hurt the network, and if so, how precisely?

Not necessarily, but if everyone did it then yes.

If everyone actually trottled upload bandwidth so much that there is not sufficient bandwidth to bootstrap new nodes, then yes it is a major hindrance to future uptake.

In general, I believe the claim is applicable to the health of any peer-to-peer network, as oppose to just the bitcoin network. If the majority of users in Bitcoin are "leechers" and do not supply sufficient bandwidth to relay blocks and transactions, then clearly the bitcoin network will become less healthy as it will be harder for nodes to come into a consistent state and harder for new nodes to join the network.


How to move/sweep your Bitcoin Core bitcoins safely and air-gapped to your new fancy cold storage?

Yes, it's possible using descriptors and PSBTs.
How to spend/sweep p2pkh UTXOs air-gapped using Bitcoin Core's GUI and  PSBTs.
Here are the required steps, most of them have to be entered into Bitcoin Core's console.
OFFLINE

export the descriptor of the p2pkh address:  getaddressinfo ADDRESS

copy the "desc": "pkh([....", output to the ONLINE computer

ONLINE

optional: create a new wallet in Bitcoin Core
import the descriptor from above into Bitcoin Core:  importmulti '[{ "desc": "pkh([....", "timestamp":0, "label":"import", "watchonly":true }]'
optional: check that the following is now "solvable":  getaddressinfo ADDRESS
now create the unsigned PSBT using Bitcoin Core's GUI
copy the unsigned PSBT (YOUR-PSBT) to the OFFLINE computer

OFFLINE

if needed unlock your wallet walletpassphrase "YOUR_WALLET-PASSWORD" 600
optional: check the PSBT  decodepsbt YOUR-PSBT and  analyzepsbt YOUR-PSBT
sign your PSBT: walletprocesspsbt YOUR-PSBT
finalize your PSBT: finalizepsbt OUTPUT-FROM-WALLETPROCESSPSBT-ABOVE
copy the hex output from above to your ONLINE computer

ONLINE

send the raw transaction using sendrawtransaction HEX-FROM-ABOVE
optional: copy the raw transaction into an block explorer like blockstream.info instead

Done!
Feedback is welcome!


Can I sign a message with an Open-PGP key?

Signing using the private key of an address does nothing for me, as it doesn't prove I control the address (I could have told someone else to sign their address).

In general, OpenPGP keys and Bitcoin keys are incompatible.

You can sign a message using the private key to sign a message that says "This address, and this PGP key are held by so-and-so."  It's possible to forge this by asking someone else with a lot of Bitcoin to claim that their Bitcoins are yours.

This is a problem that doesn't really have a good solution. You can give them the private key and ask them to derive the public key, to prove that you own that address. However, if you do that, an unethical lawyer could steal your Bitcoins.


How do miners/clients prove a transaction is valid?

Bitcoin doesn't work on balances, it works on transaction inputs and outputs. A transaction's inputs must specify unspent transaction outputs (UTXO) of previous transactions. And clients maintain an index of UTXO to easily find the referenced outputs.


As the founder of bitcoin-otc, I think I'll be able to help you out here. :)

OTC uses gpg (the free software implementation of the PGP protocol) for authentication. So your first step is to register on OTC with your gpg key. The OTC wiki contains detailed instructions on this page: http://wiki.bitcoin-otc.com/wiki/GPG_authentication

The rating system is a web of trust links between users. There is more documentation on the rating system here: http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System . I suggest that you pay particular attention to the 'relying on the rating' section.

Trades happen p2p - the OTC system is only an order aggregator as far as trading is concerned. Once orders are placed (which is not even a requirement, you can just hang out on the IRC channel and set up trades without ever using the order book), it is up to the individuals to talk to each other and set up the trade details.

From the order book view, you can see a person's ratings by clicking on his/her username.

The bitcoin-otc system is not a for-profit entity, nor a profitable one. There are no fees charged by the system for users to register and place orders. All order execution happens directly between people, the otc system does not intermediate either side of the transaction.

Overall, there is plenty of documentation on the OTC website and wiki; I invite you to give it a read for further details. A good starting point would be the main user guide page: http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc


The pool might be adjusting your share difficulty level. For example, you might be mining at 50 KH/s and the pool is setting your share difficulty at 16. If you then increase your hashrate to 100 KH/s and the pool changes your share difficulty to 64, then you will submit shares half as fast, but receive four times as much credit for a share at difficulty 64 as a share at difficulty 16. Ultimately, you get paid twice as much mining at 100 KH/s as at KH/s, so don't worry about it.


How to verify that downloaded files such as Ubuntu, BitcoinQT, Armory, and Electrum have not been tampered with?

It all depends on the security mechanisms of your operating system. On Ubuntu, packages are signed, and the installer checks the signature. So, a man in the middle, or a rogue mirror site could not have modified the copy of Electrum that I installed.

The safety of your bitcoins on your machine does not depend only on your bitcoin applications. If the operating system itself is compromised, it can steal your bitcoins (using a keylogger to find the possible passwords) so pay attention to use a safe operating system, with security updates and so on.


Namecoin: Is it possible to move a name_new to another wallet? How?

Each name registered in Namecoin is associated with an address. When updating a name with name_firstupdate or name_update operations, Namecoin wallet will automatically transfer it to a new address within the wallet.

Between name_new and name_firstupdate, there is no way to transfer a name to a different address (but it is still possible to register the same name a second time). However, it is possible to transfer an address to a different wallet. You would need to find which address the name_new operation is associated with (for example, by using block explorer). Then export the private key associated with that address and import it into another wallet. Now you would be able to issue name_firstupdate command from that wallet (you will need to use the four-argument form of the command). This will transfer the name to a different address, so the old address would not be used anymore.


How is a transaction not present in 2 or more solved blocks?

When node B gets informed about block A being mined he would start working on a new block that does not conflict with the first one.

If block B happens to be mined around the same time as block A there would be a fork. All nodes in the network that hear about both blocks will keep both branches and will wait for the conflict to be resolved.

The miner that mines the next block will have to place his new block on top of one of the branches. When that happens and the new block gets broadcasted, all nodes will pick the branch with the most work and the other branch will become orphan.


Do I need a full node to perform OP_RETURN transactions?

You do not need to run a full node in order to submit a transaction, regardless of which OP codes that transaction contains.  Any node that can submit transactions to the Bitcoin network will do.

What you should look for instead, is a library in your chosen language that allows you to construct transactions manually, rather than using templates for typical payment transactions.  Once you have a transaction constructed, you can broadcast it to the network via whichever type of node you feel like.


What can I do with "unspent" transactions? Can I transmit them to a chain?

When someone sends you bitcoins, they do so by submitting a Bitcoin transaction to the network. Transactions specify which coins they spend in the inputs, and allocate the funds to new owners on the output side. You received one such transaction output. While the other output got used already, your output is still marked as "unspent". "Unspent" in this context means "not spent yet" in the sense that it is still available to be spent. When you want to spend your bitcoins, you can use your wallet to create a transaction to send some or all of them to another Bitcoin address.


Python: How generate bitcoin addresses using electrum library

The derivation path you used is incorrect. Electrum does not use bip44. Anyway here's one way to do this for p2pkh addresses:

from electrum import bitcoin
from electrum import keystore

seed = "<seed here>"
change = False
address_index = 0

k = keystore.from_seed( seed, '', False )
print( bitcoin.pubkey_to_address('p2pkh', k.derive_pubkey( change, address_index ) ) )


How to keep my bitcoin safe when I move my bcash?

Bcash transactions cannot be replayed on the Bitcoin network, and vice versa, Bitcoin transactions cannot be replayed on the Bcash network. This is called 2-way replay protection. In Bcash's case, it's implemented by the mandatory use of a sighash flag that's invalid for a Bitcoin transaction.


Is there a way to accept bitcoin payments and verify the identity of the people who paid without asking for any other information?

You could have the customer send a message signed with the Bitcoin address used. This can be done with most Bitcoin clients or with most of the online wallets. This proves they have access to the private key for that address and are the owner.

Where they send the email from is not important as long as you can verify the message.

https://blockchain.info/wallet/features

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

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

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


Why is it so difficult to track & recover stolen Bitcoins?

Transactions can occur very quickly and the stolen coins can exchange hands, split up and be mixed with other coins multiple times before the theft is discovered. Many innocent parties (whether it is merchants, exchanges or other individuals) could be affected. Who is going to be holding the bag?


How to find the shortest unused FirstBits?

Yes there is a solution, it is brute-force. Make a loop and add variable characters, test them one by one. Start with one variable characters, try all combinations, add another variable character, try all combinations, rinse, repeat until you find unused firstbits.


Port Forwarding for Bitcoin Core in order to allow incoming connections?

External host is the IP of the host connecting to you. If you want to allow anyone to connect, you can just put 0.0.0.0.


Can you try to add/modify with the with the following lines of codes in your methods:

private static JsonObject getAuthenticatedData() {

  String timestamp = Instant.now().getEpochSecond() + "";
  String accessSign = getAccess(timestamp);

  con.setRequestProperty("CB-ACCESS-TIMESTAMP", timestamp);
  con.setRequestProperty("accept", "application/json");
}

public static String getAccess(String timestamp) {

  String prehash = timestamp+"GET"+"/accounts";
  byte[] secretDecoded = Base64.getDecoder().decode(secret);
  SecretKeySpec secret_key = new SecretKeySpec(secretDecoded, "HmacSHA256");

  hash = Base64.getEncoder().encodeToString(sha256_HMAC.doFinal(prehash.getBytes()));

  return hash;
}


Sending bitcoins programatically without running a node

Yes this is completely possible. There are services which run fully featured API's that provide almost everything that the client can do.

http://blockchain.info/api

There are other merchant processors which have similar functionality depending on exactly what you want to do also.


Transaction created with sendtoaddress didn't propagate to the network, how to resend?

If you have the transaction ID you can get the raw hex transaction via:

bitcoin-cli getrawtransaction <txid>

That will produce a rather long string <rawtx> which is the serialized transaction. You can then use

bitcoin-cli sendrawtransaction <rawtx>

or any of the web interfaces that allow pushing a transaction (just search for pushtx and I'm sure you'll find a few providers). The raw transaction does not contain any private information. It is safe to publish, however services may attribute the transaction with your IP if you use them, so try sendrawtransaction first, which is the exact same behavior your client would use anyway.

Notice that your client will also automatically retry your wallet transactions every once in a while, so manual intervention may not be needed. It could be you haven't attached a large enough fee for the TX to be propagated in the network.


Where can I find the official documentation of blockchain technology

Nowhere. There is no official body in charge of "blockchain technology".

There are many different individuals, groups and organisations all doing their own "blockchain" work more or less independently. They will often base their blockchain partly on older blockchain ideas. Each of these groups may or may not publish a definition of the blockchain they are using.

One example is the Bitcoin Developer Reference written by some ever-changing random group of mostly anonymous/pseudonymous people whose motives and accuracy you have to make your own judgement about. I suspect they are mostly OK but you have no recourse if I or they are wrong misleading or even maliciously deceptive.

The nearest thing to an official definition would probably be Satoshi Nakamoto's white paper published in October 2008. If you read and understand that, you are well-placed to implement your own blockchain. You'll need a grounding in basic cryptographic principles and algorithms (don't write your own cryptographic algorithms).

  we want to work with blockchain.

If this comes from marketing, ignore them and just add the word "blockchain" liberally to product names, documentation etc :-)

Note that The Economist Sept 1st 2018 has a 12-page section on blockchain

Although mostly positive about blockchain, it does have many cautions.

  because of its decentralised nature, a blockchain will always be slower and more cumbersome than a standard database.

Their separate lead article says:

  A few organisations, such as SWIFT, a bank payment network, and Stripe, an online payments firm, have abandonded blockchain projects, concluding that costs outweigh benefits. Most other projects are experimental.

The idea of replicated peer-to-peer databases with strong controls on integrity based on public-key cryptography goes back to at least 1984 when Ray Ozzie et-al formed Iris associates to develop Lotus Notes. Anyone selecting "blockchain" needs to have a deep understanding of which of it's characteristics are vital to their project, what alternatives exist and what the trade-offs are.


Bitcoin daemon sends "Empty reply from server" when in test net

I leave it here. Because i spent about two days on it :-o
https://github.com/bitcoin/bitcoin/issues/10218

  Authentication is not optional. Configuring it yourself is optional, but bitcoind never accepts RPC connections without explicitly or implicitly configured username/password.

So, I just added user and pass from file /root/.bitcoin/.cache.
And get this:

curl --user __cookie__:96fea535b009e62ddffe1c6f5090c50396d17e7f96d0b0a75eb580bdd1771d29 --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getinfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:8332


Try LocalBitcoins:

https://localbitcoins.com/buy-bitcoins-online/paypal/

https://localbitcoins.com/sell-bitcoins-online/paypal/

If you are selling Bitcoins make sure the buyer is reputable - pick a Sell Bitcoins online advertisement with green thumb.

Please note that the buy price is higher with PayPal, because the sellers price in the risk of doing business on PayPal.

If you trading with unknown party make sure you follow the risk mitigation procedures. PayPal, by the reports, is very common method for doing fraudulent purchases.

Usually exchanges expose no user information about the trades, so they are very hard to trace. But if you wish to add an extra layer to hide the origin of Bitcoins you can use mixer, which itself might not be a safe procedure.


How do I build Bitcoin source in Windows 7?

Take a look at Windows Build Instructions By Matt Corallo, it's outdated, but has some additional comments to the included doc.

  Install:

  MinGW Automated Installer from
  http://sourceforge.net/projects/mingw/files/OldFiles/mingw-get-inst/mingw-get-inst-20110316/.
  Install with the C++ and MSYS options checked.
  Activestate Perl (for building openssl) from
  http://www.activestate.com/activeperl/downloads.  You don't need
  anything except ActivePerl and Perl, none of the other fancy crap.
  You do want to add Perl to your PATH (its an option in the
  installer).

  Download:

  WxWidgets 2.9.1:
  http://sourceforge.net/projects/wxwindows/files/2.9.1/wxWidgets-2.9.1.zip/download.
  Unzip to C:\wxWidgets-2.9.1-mgw
  OpenSSL 1.0.0d:
  http://www.openssl.org/source/openssl-1.0.0d.tar.gz.     Untar  to
  C:\openssl-1.0.0c-mgw (yes bitcoin is designed to build with
  1.0.0c, but might as well use the latest version since it works right?) Hint: untar using the tar binary which is included in MinGW (do not use 7-zip, it will not handle symlinks correctly) using cd \c\ && tar xvvf\c\Users\Matt\Downloads\openssl-1.0.0d.tar.gz && mv openssl-1.0.0d openssl-1.0.0c-mgw in the msys shell
  Berkeley DB 4.7.25 NC: http://download.oracle.com/berkeley-db/db-4.7.25.NC.zip.  Unzip to C:\db-4.7.25.NC-mgw
  Boost 1.43.0:
  http://sourceforge.net/projects/boost/files/boost/1.43.0/boost_1_43_0.zip/download. Unzip to C:\boost-1.43.0-mgw
  Boost Jam:
  http://sourceforge.net/projects/boost/files/boost-jam/3.1.18/boost-jam-3.1.18-1-ntx86.zip/download. Unzip wherever you like, I used C:\bjam
  miniUPnPc binary
  http://miniupnp.tuxfamily.org/files/download.php?file=upnpc-exe-win32-20110215.zip.
  Unzip to C:\upnpc-exe-win32-20110215
  miniUPnPc source
  http://miniupnp.tuxfamily.org/files/download.php?file=miniupnpc-1.5.20110215.tar.gz. Untar to C:\upnpc-exe-win32-20110215\miniupnpc (you only need *.h, but the others won't hurt) untar with cd \c\upnpc-exe-win32-20110215 && tar xvvf \c\Users\Matt\Downloads\miniupnpc-1.5.20110215.tar.gz && mv miniupnpc-1.5.20110215 miniupnpc

  Note that the reason for using the binary miniupnpc release is that I
  was unable to get it to build on my system.

  Add C:\MinGW\bin to your PATH environment variable (Google is your
  friend as it depends on your Windows Version).

  In the DOS Shell:

  wxWidgets:

cd \wxWidgets-2.9.1-mgw\build\msw
mingw32-make -f makefile.gcc

  Boost:

cd \boost-1.43.0-mgw
\bjam\bjam.exe toolset=gcc --build-type=complete stage

  In the msys Shell (MinGW shell in your start folder or
  C:\MinGW\msys\1.0\msys.bat):

  OpenSSL:

cd /c/openssl-1.0.0c-mgw
./config
make
perl util/mkdef.pl 32 libeay enable-static-engine > libeay32.def
dllwrap --dllname libeay32.dll --output-lib libeay32.a --def libeay32.def libcrypto.a -lws2_32 -lgdi32

  Copy the libeay32.dll file
  to the folder where you are building/running bitcoin.

  Berkeley DB:

cd /c/db-4.7.25.NC-mgw/build_unix
sh ../dist/configure --enable-mingw --enable-cxx
make

  Bitcoin

  If you wish to use git to pull keep a local repository, you'll have to
  download msgit from
  http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.4-preview20110204.exe&can=2&q= . Otherwise, you can download the latest zip of bitcoin from
  https://github.com/bitcoin/bitcoin/zipball/master In the msys shell,
  cd to the unzipped location and

make -f makefile.mingw

  Run with ./bitcoin.exe (make sure you have the libeay32.dll in bitcoin
  folder)


What is the best way to prevent replay attacks in the event of a bitcoin hard fork?

One solution we brainstormed, was using some coins that were only valid on one chain (for example newly mined coins) and adding 1 satoshi of "taint" to all generated transactions. This would work but is not perfect.

It so sounds like you have two problems:

How to get some inputs that are only valid on one side of the chain.
How to mix these inputs in with all of your transactions.

I don't have any good answers for the second question; you'll have to mix in the inputs by either putting them in every transaction you send or by mixing them with a large amount of coins which you then split into dozens or hundreds of inputs that you'll use normally.

For the first question:

Coin splitting

The best way would be to push for replay protection in the hard forking client(s) as they're already changing the rules.  But if that's not possible, there are some potential differences between chains that can be used to get one version of a transaction confirmed on one chain and another version of the same transaction confirmed on the other chain.

I'll warn that (1) Bitcoin clients are not designed to operate under ongoing hard forks, so lots of things that would normally work just fine can end up resulting in monetary loss, (2) without replay attack protection, there's no guarantee that any of the mechanisms below will split your coins---so you should probably send the coins from yourself to yourself so that, if the split fails, you still have all your coins (minus any transaction fees), and (3) in a hard fork, any rule can be changed, so the following generic information may not apply on the hard-forked chain; check with the hard fork developers to be sure.

Methods:

Coinbase transactions: not the kind your company makes, but the kind miners use to claim subsidy and transaction fees.  As your question indicates, these are only valid on the side of the hard fork they're generated on but they also have to wait 100 blocks to mature.

Pros: simple, guaranteed to work

Cons: requires miner help, have to wait 100 blocks
nLockTime: if the two chains diverge in height, you can create a transaction with the nLockTime set to the height of longest chain.  That transaction can be immediately confirmed on that chain, but it can't be added to the shorter chain until that chain catches up to the same height---giving you a window of time into which to broadcast an alternative transaction on the shorter chain and split your coins.

Handily, Bitcoin Core has a feature called anti-fee sniping that automatically (in current versions) sets the nLockTime to the current block height for default wallet transactions, so this trick is pretty easy if you just want to split your Bitcoin Core wallet.

Pros: should be pretty effective because it depends on consensus rules

Cons: you still need to wait a few blocks after the fork to give the chains time to diverge in chain height.

(Credit: I first heard of a method like this from Peter Todd; I don't know if he originated it, nor if this is exactly the method he was thinking about---I had to guess at how it would work from him just saying "use nLockTime".)

You can also do the same thing with consensus-enforced nSequence, but it doesn't get you anything extra.
Fee differences: It's possible miners on one side of the fork may be mining transactions with lower fees than on the other side, so you can broadcast a low-fee version of your transaction on the low-fee chain, wait for it to confirm, and then broadcast a higher-fee version on the high-fee chain.

Pros: simple

Cons: you may still have to wait a few blocks for fees to diverge by much and since each miner has their own policy, you may need to try multiple times.  Also, many wallets don't let you chose arbitrary fees (they just give you a reasonable fee or let you choose from reasonable range of fees).

(Credit: I first heard this described today by @ElectrumWallet on Twitter.)
Find some other feature that diverges between miners on the two chains.  For example, as I write this, I think Bitcoin Core by default will not accept into its memory pool any transactions that require mining more than 20 ancestors first (this prevents abuse and allows the mining code to run more efficiently, since Bitcoin Core provides child-pays-for-parent (CPFP) mining); Bitcoin Unlimited, being based on an older version of Bitcoin Core, doesn't provide the CPFP optimization and so will allow an unlimited depth of transaction ancestors to enter the mempool.  This means you could get, say, 101 related transactions mined on one side of the fork and then you'd have up to five block to get a different 101st transaction mined on the other side of the fork.

There are potentially other of these relay-level differences between clients that could be used.

Pros: relay differences could possibly be used immediately after a hard fork to get a transaction mined in the first fork block (if you knew when that was going to happen) or the second fork block (if you started as soon as the first fork block was produced).  Also, they may be fairly simple.

Cons: these tricks depend on all miners on one side of the chain running one version of the code and all miners on the other side running a different version of the code.  The more overlap there is, the lower the probability these tricks will work.


cpu, ram or bandwidth -- what is most important for bitcoin mining?

CPU is basically the only thing that matters.

The memory requirements for mining are trivial (enough to run bitcoind; SHA256 uses only a few bytes of memory).  Having more that enough will add no benefit.  Disk performance is nearly irrelevant also.

A fast network connection may help you get new blocks a little bit faster.  This is helpful because the time in between when a new block is released and when you get it is effectively wasted mining time.  But even with a very slow network connection, this should be at most a few seconds.  With a 10 minute block time, the difference between the slowest and fastest network connection should impact mining efficiency by less than 1%.


Why does bitcoin-cli not know about working directory of bitcoind?

The bitcoin-cli use the bitcoin-rpc, so for used a bitcoin-cli, you must ran the bitcoind with the configuration and when it is OK, you can get command with the bitcoin-cli

A simple file configuration could be it

##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##
# On client-side, you add the normal user/password pair to send commands:
rpcuser=alice
rpcpassword=bob

or you can run the bitcoind with this command bitcoind -rpcuser=alice -rpcpassword=bob


Why aren't block solutions sent to a multicast address?

Multicast just doesn't work very well over the Internet. Relaying just works better. One big problem is that multicast provides no way to police emitters of junk while relaying allows each relayer to verify information prior to relaying it, preventing an attacker from getting amplification.


it looks like the server rejected the connection from  client, try use this rpcallowip instead and see if it helps.

rpcallowip=0.0.0.0/0

Above decrease the rpc security but will allow all connection reguardless their ip address


Unable to access Wallet in Multibit HD - currupt password

I have the same issue. It seems MultibitHD is not able to restore wallet at all. I removed everything related to it from AppData (first created backup), uninstalled application, restarted PC, installed again and tried to restore wallet. Wallet words accepted, wallet backup file loaded and last screen hangs with "X wallet not created" and "Synchronizing please wait till completed". It never completes I can tell.


btc transaction show all btc moved from wallet

I'm 99.9% sure the 'unknown' address is the 'change address' of your wallet, being returned back to your wallet. If you check the balance of your wallet, is it what you think it should be?

You should read this: http://support.exodus.io/article/109-what-are-bitcoin-change-addresses


How do I find the hash "market share" of P2Pool?

In concept, P2Pool is much stronger than centralized pools. Unfortunately, most centralized pools still hold a high hash-rate.

You can see the global hash rate, and its distribution at http://bitcoinwatch.com/

My opinion is that miners are used to using slush, deep bit, and btcguild - and are either unaware of the incentives of P2Pool, or don't care.


This transaction attempts to exploit the recently disclosed (and fixed) vulnerability regarding the validation of duplicate inputs in a single transaction.

There is an excellent answer on this question on how that vulnerability works.


what is exact meaning of some field of response of `getBlock` rpc api

size refers to the size of the block, which is 80 bytes for the header + sum(tx_sizes). As pointed out in the comments, this includes the segwit data and is meant to match the actual, on disk size of the block.

bits refers to nBits, which encodes the target difficulty for the block. You can see an explanation of the encoding scheme here.

chainwork represents the sum total of the expected hashing operations required to product the chain up to this block - this means that you cannot use it for calculating the hash power for the current block, as it is the sum of all the hashing required to produce every block from the genesis block up until the current block.

In fact, you can never get a precise measurement of the active hash power based on a single block. However, there are ways to calculate the average/expected hash power on the network at a given point in time, as described in this question.


You very probably have a massive wallet.dat file.

This happens with Instawallet's bitcoind, it takes an hour to start up, it spends this time loading the wallet.

If you want to make sure :

Stop bitcoind
Open up a Terminal, and type :
$ tail -f ~/Library/Application\ Support/Bitcoin/debug.log
Press ⌘K to clear the scrollback and window
Start bitcoind

You should see some output when the client starts, if the problem is actually with loading the wallet the output should stop for a while on 'Loading wallet'.


Bitcoin sent to a defunct address - what happens to it?

If the address is valid then the bitcoins will stay there until spent.  If you don't have the private key for that address they are now unspendable.

However, in general Bitcoin uses addresses in a different way to that which might be considered immediately obvious.  An address is generally considered a single-use item and as such it is entirely possible that your wallet contains the private key for the address to which you sent these coins, as well as any other addresses which you might have created.  Take a look at your wallet to see if it is present.


The address 13ggzjqKyFGQZtxNWUoG4BFDPAgdBijUe4 is generated from a different word list, not the one you mentioned.


unable to get transactions in wallet console

To retrieve arbitrary transactions in the Bitcoin Core console, you need to use the txindex=1 option in your configuration file.

Note that setting that option will trigger a full rescan of the blockchain that might (depending on your setup) take several hours to complete.


Check if multiple signatures match a specifc public key

I believe it could work with a RedeemScript like this (haven't tested the scripts):

OP_IF
  3 <pub_A><pub_B><pub_C> 3 OP_CheckMultiSig
OP_ELSE
  1 <pub_A><pub_B><pub_C> 3 OP_CheckMultiSigVerify
  4 <pub_S1><pub_S2><pub_S3><pub_S4><pub_S5> 5 OP_CheckMultiSig

Explanation: The redeem script has two parts:
- OP_IF: this part could be removed, it is there to allow the "leaders" to spend the funds without needing the "shareholders" signatures. Depending on the purpose it could be removed (remove first 3 lines of RedeemScript and signature doesn't require OP_TRUE/OP_FALSE in it).
- OP_ELSE: this provides what you need with 2 multi-signature operations. The first one requires at least one signature out of 3 "leaders" signatures and performs a OP_CheckMultiSigVerify (there is no true/false remaining on the stack after the execution) and the second one requires 4 of 5 signatures from "shareholders".

To spend, either one of these signature scripts should be provided (OP_0 is mandatory due to the bug in CheckMultiSig OPs):

OP_0 <sig_A><sig_B><sig_C> OP_TRUE <RedeemScript>

or

OP_0 <sig_S1><sig_S2><sig_S4><sig_S5> OP_0 <sig_A or B or C> OP_FALSE <RedeemScript>


Why can't we design a bitcoin that does useful work?

Solving SHA256 hash problems on Bitcoin is useful in the sense that secures the Bitcoin blockchain, but if your question is: "why can't it do something computationally useful as a side-effect?", then I think the answer is "we don't know how". For Bitcoin to work, the proof-of-work that miners do must have the following properties:

Easy to verify solutions
Hard to find solutions
Difficulty of finding solutions can be precisely quantified
Provably inseparable from the block it secures

Cryptographic hash functions like SHA256 satisfy these four properties. I don't think automated theorem proving fits the bill because, as far as I'm aware, there is no way to prove how difficult it was to find the theorem that you proved. General purpose grid computing, like BOINC, doesn't fit the easy-to-verify requirement, at least in the context of Bitcoin. (In fact, I think this is an active area of research in grid computing, called the "cheating problem".)

If there some proof-of-work scheme that satisfies these four properties and also has some useful computation as a side-effect, that would be interesting. I'm not aware of any.


Is there a way to prove ownership of a transaction?

You cannot "own" a transaction. But you can own the private keys for one or more of the addresses from the inputs of the transaction.

A (regular) transaction must be signed with the private keys of the addresses of all the inputs. So if you own one of the addresses, the transaction could not have been verified without you, which may count as "ownership" if you want to call it that way.

Proving that you own an address can be done by signing a message using the private key of that address. Most wallets provide signing functionality. Just agree on a message, something like "I, [name with which the other party knows you], am the owner of address [address from the input]." After signing, you can send the message and the signature to the other party and he will be able to verify your ownership of the private key.


What happens once mining speed gets close to zero?

I think you are confusing two things here:

Block generation rate
New bitcoins introduced per block

Blocks will always be found at a rate of approximately one per 10 minute. The difficulty of finding a block adjusts itself according to how many people are trying. Simply said, if N people are mining (all with equal hashing power), they will each (on average) find one block per N*10 minutes.

On the other hand, the newly introduced currency in each block is currently 50 BTC/blocks, but somewhere end 2012 this will decrease to 25 BTC. 4 years later, it will become 12.5, and so on. Around 130 years from now, the last block with non-zero new coins will be created. After that, mining will still continue, but blocks will only have transaction fees as rewards, and no new currency anymore.


Is Kim Dotcom's "Megacard" a viable possibility for bitcoin?

This type of product has been tossed around since at least May 2011 when MagicalTux was the new owner of Mt. Gox.  They no longer discuss it.

BitInstant "leaked" such a Mastercard in Fall 2012.  They claim it is "seeing progress" but there's nothing yet.

There are similar cards.  Peter Schiff's Euro Pacific Bank offers a gold-backed debit card where gold funds are sold when using the debit card to make purchases using fiat.  But that is not available to customers from the U.S.


To create a coinbase transaction you need to send this RPC command to your Bitcoin-Qt
createrawtransaction '[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":2147483647}]{"Your Bitcoin Adress":Amount}'
Why 2147483647 ?
Because the vout must be numeric, and you can't put 0xffffffff
So this will give you 0x7fffffff and the easiest way to do that is to change manually the 7 to f
Now as required in BIP34 you must include the block height inside the scriptSig otherwise your coinbase transaction will not be valid
PS: Be aware of little and big endian


Why OP_RETURN should be used instead of raw data?

There are two reasons why you should prefer a scriptPubKey of OP_RETURN <data> over <data>.

The first reason is that the non-OP_RETURN output is not prunable, and is actually anyone-can-spend if the data is non-zero. Non-prunable outputs make the unspent transaction set larger, which slows down initial block verification and block propagation times.

The second reason is that the non-OP_RETURN output is nonstandard, meaning that not all miners will mine it. Therefore, it will take longer to get into the blockchain.


I used a local honey badger bitcoin atm to buy 250.00 CAD worth of bitcoins, where did it go?

It is advised to put your address into a block explorer such as https://blockchair.com/bitcoin (or several block explorers) to see if the network is aware of a transaction sending money to it.
You should also double-check that the address on the receipt is one of your wallet's addresses. (The main address displayed by the wallet may have changed by now, but it should be possible to open up a list of past addresses).
Most (all?) explorers show transactions even if they are unconfirmed. So if there is no such transaction on the explorer, you should take up the issue with the operators of the ATM.
If the transaction appears on explorers unconfirmed, it may mean you will see it in your wallet when it is confirmed.
If the transaction is confirmed but you still can't see it in your wallet, it may be an issue with your local wallet.


Is it legal to use bitcoin in a domain name?

To date, no entity has trademarked word "Bitcoin" in the US. This means that it's highly unlikely that any US entity would file against your domains under the ICANN Uniform Domain-Name Dispute-Resolution Policy.

There was a servicemark application for Bitcoin, but it was abandoned in July 2011.

Related trademark applications

Bitpay applied for Merchant Solutions for the bitcoin currency and Bitcoin Merchant Solutions, both also abandoned.
There is one for Bitcoin appliance, also abandoned.
Bitcoin Magazine applied for a trademark, and it's still in processing.


How do I find the txid and vout values for an input I want to spend?

If you want to send some coins, you have to have been given some coins before.

When someone sends coins to you, they make a new transaction. This transaction has a TxID (which is the double SHA256 hash of the raw transaction bytes) that everyone uses to refer to this transaction. A transaction can have multiple outputs, and each outputs allocates some of the previously unspent transaction outputs (UTXO) that were used as inputs in the new transaction.

So, really this question comes down to: what are bitcoins? Bitcoins are a pair of TxID and an index that uniquely specify an entry in the blockchain.

The developer documentation (https://bitcoin.org/en/developer-documentation) goes into great detail if you want to learn more.

As far as how do you actually get your hands on these values, you just have to have someone send you coins to your address (or mine them), and then you could just look your address up on a blockchain explorer and find any unspent outputs it has. From there, you can just use the web interface to see the txid and the output index. For example, I just grabbed a random transaction off from blockchain.info at https://blockchain.info/tx/86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7. You can see the txid is 86e06fed6f597dc212e72556a84660d84e9536e081719624a0a30a685238d0d7 and that there are two outputs (indices 0 and 1), the first of which has been spent, and the second one which has not been spent (at the time of writing).


getwalletinfo does not take parameters.

It sounds like what you are looking for is how to send getwalletinfo to a certain wallet loaded into Bitcoin Core. The way to do this is to use that wallet's API endpoint. The endpoint is /wallet/<name> where <name> is the name of the wallet you are trying to send commands to.

So the full URL that you need to send your RPC requests to is http://<ip>:<port>/wallet/<name> where <ip> is the IP address that Bitcoin Core is listening on (probably 127.0.0.1), <port> is the port the RPC interface is bound to (probably 8333), and <name> is the name of the wallet.


Bitcoin is meant to be a decentralized network not requiring trust to make/receive transactions. Transactions contain signatures to prove that they haven't been tampered with. Signature is not just the private key, it is something that is derived by the private key and some other parameters. This is called ECDSA, Elliptic Curve Digital Signature Algorithm. If the crypto implementation is proper, it's impossible to extract the private key from signatures.

Changing the blockchain is a different topic. Each block contains "Proof Of Work", which means its hash (a value to check a block's authenticity, but no private key) would change if any part of the block is altered. This'd invalidate the block, and miners would have to re-mine that block (change little things until the hash is lower than a value, the target) But if you create a fake chain with lower targets for blocks, then your chain would have have less Proof Of Work accumulated and other nodes would switch to the chain with the largest PoW once they're aware of it. (But in practice there are checkpoint blocks, so the initial target for remining a chain is high)


Stopping Hash field in GetBlocks Message

Node1 announces block B3, using an 'inv' message with B3's gash.

Node2 does not know about B3, or its parent B2, but does know the grandparent B1. It sends a getblocks message, starting from B1, but stopping at B3.

Node1 replies with an inv for B2, but not with B3 or any potential successor B4 thay may have appeared.

The purpose is just avoiding sending too many hashes in case the sender already knows some successor.

Note that since Bitcoin Core 0.10.0, getblocks is no longer used. getheaders has similar logic though.


How to replicate getaccountaddress behaviour using getnewaddress and labels api

It is possible to mimic the same functionality of getaccountaddress using a label.

This is an example in python:

#!/usr/bin/env python3

import bitcoin.rpc

bitcoin.SelectParams('regtest')
proxy = bitcoin.rpc.Proxy()

def get_unused_address():
    label = 'donations'
    unused = None
    try:
        addr_list = proxy.call('getaddressesbylabel', label)
    except bitcoin.rpc.JSONRPCError as err:
        if err.error['code'] == -11:
            # No addresses with label
            addr_list = None
    if addr_list:
        # Addresses with label found
        for addr in list(addr_list.keys()):
            # Check for tx received
            r = proxy.call('listreceivedbyaddress', 0, True, False, addr)
            if not len(r[0]['txids']):
                # Unused address found!
                unused = addr
                break
            else:
                # Used address found, remove label
                proxy.call('setlabel', addr, '')
    if not unused:
        # Address with label not found, generate a new one
        unused = proxy.getnewaddress(label)
    return unused

print("Unused address is: %s" % get_unused_address())


How to determine first byte (recovery ID) for signatures (message signing)?

FWIW this is what I have found regarding this question. Basically there are two ways of finding what libraries call "recid" or recovery ID. Most of them use the first method but there is another way:
Method 1:

Only requires r and s so it can be performed by anyone as long as you have the signature and the "message" that was signed.
It is so much slower because it has 3 scalar multiplication and based on cofactor of the elliptic curve used the whole operation may be repeated 2*(h+1) times, which is up to 4 times for bitcoin with secp256k1 curve (99% of the time it is 1 or 2 times).

The steps are explained in section 4.1.6 of SEC:1, I won't repeat them here.
To find recid you check the calculated public key with the given public key or hash of it and report number of rejected public keys as recid. For example if x=r+(0*order) and Q was used then recid=0 and if -Q was used then recid=1 and so on.
method 2:

It requires full r or R=(xR, yR) so it can only be done while signing (requires having the private key).
It is much faster because there is no additional calculations. It just needs value checks which are fast.
This is usually referred to as v in libraries

byte v = if(R.X > curve.N) then 2 else 0) | (if R.Y.IsEven then 0 else 1);
Basically it is check to see if xR is bigger than curve order (N) and whether yR is even or odd. Something that should not be forgotten is a "flip" that is performed based on s and whether s was used in the signature or -s
if s > curve.N/2 then v^=1 else do nothing
** Note that in the end you need to calculate the following:
recid = 27 + v + (if compressed 4 else 0)


BIP-32 - how can parent extended public key exposed parent extended private key?

I am interested to understand as per bip32, why would anyone share the 'parent extended public key'?

The purpose of sharing the parent extended public key is so that child public keys (and thus addresses) can be derived from it without needing to know about a bunch of addresses individually. This is easier for separated setups where an online computer only has the public keys as the online computer does not need to be constantly refreshed with more addresses to watch for. It can generate the addresses itself.

  In such case, will knowing 'child extended public key' expose 'parent extended private key'?

No. Only knowing both the parent extended public key and a child private key derived with unhardened derivation exposes the parent private key.


How does Bitcoin verifies signature if addresses are one way hashed

The ECDSA public key is "included" in the new transaction (part of the scriptSig).
Details
This is an example output of a transaction (only hash of the pubkey is available):
"scriptPubKey": {
    "asm": "OP_DUP OP_HASH160 059be22aadc3bef6b673cb7a16247a0b7403d943 OP_EQUALVERIFY OP_CHECKSIG",
    "hex": "76a914059be22aadc3bef6b673cb7a16247a0b7403d94388ac",
    "reqSigs": 1,
    "type": "pubkeyhash",
    "addresses": [
      "mg2cQz9Y3ugyjfq8b2wTcW4veemgTBKxkX"
    ]
  }

The pubkey from the address above is
03788e5414ebec4a38032be706ae0c13870e320d916bb087ab7258fcf8c0111cbf
(but it's not visible in the blockchain until the output gets spent. Only the recipient of the output above knows it.)
Using that output as an input in a later transaction will result in:
"scriptSig": {
            "asm": "304402203b47249bfe6528dcf297c5888ad608a5c7227ea9f878df09a265c3318c1482e202204e8a8f17da505a6d20ceb4eb63fba2d8e2c5d0a792a0e280dcb18adeec68a05d[ALL]03788e5414ebec4a38032be706ae0c13870e320d916bb087ab7258fcf8c0111cbf",
            "hex": "47304402203b47249bfe6528dcf297c5888ad608a5c7227ea9f878df09a265c3318c1482e202204e8a8f17da505a6d20ceb4eb63fba2d8e2c5d0a792a0e280dcb18adeec68a05d012103788e5414ebec4a38032be706ae0c13870e320d916bb087ab7258fcf8c0111cbf"
          },

(3044... is the DER encoded ECDSA signature)
(03788... is the pubkey)


Bitcoin backend integration - Do I really need the notion of "a wallet"?

I understand what GUI wallet softwares are and why those are important for end users. But in a backend application, if I understand correctly, a wallet is simply a seed that can generate some private/public keys pairs in a deterministic way. Is that correct?

Correct, but you miss the most important feature of a wallet...crafting transaction / bitcoin script! And that part is not trivial as it involves such things as coin selection algorithm, bitcoin standard script +~segwit(also for generating segwit address), signatures etc.

What matter in the end are the key indeed... but you should not underestimated what feature does a wallet provide and instead of persisting tons of encrypted priv key you should definitively take a look of HD wallet (BIP32, BIP44, BIP49, BIP84)which are "basically" a determinist way given a seed / mnemonic, to handle an infinite amount of key. This way you could just persist paths.

See a wallet more like a tool, or a library a module a package whatever, you would require that I'm pretty sure, because when you mention "create inputs using them, create a transaction that I would sign, and then broadcast that transaction", that's what a wallet does.

About you received/send, I guess you have to handle or take into account a given transaction state, mined, validated (~6 confirmations, depends your requirements) or not. This way your app will behave differently. Basically you need a node or an API and a wallet "package" tool which will bridge the gap between your app and the node.


Specify which CPU threads are used using cpuminer

Don't worry about it, just let your OS take care of the scheduling. As long as you're not trying to run more CPU-bound threads than you have cores, you'll be running as efficiently as you can. Even a single threaded program will bounce around between cores (you can see this by looking at a CPU usage graph, and your single threaded program will probably use 25% of each of a quad core system on average).


Moving armory watching-only .wallet file

You can just import the watching-only wallet on system "C".  In fact, no reason to remove it from system "B" (if you don't want to).  It's okay to have multiple "watchers" of a given wallet.  Moving the watching-only wallets around doesn't actually move the coins, it just changes which computers recognize coins for which the offline computer has signing authority.


Because all these altcoins run on different TCP ports and furthermore (fair) nodes won't relay invalid messages (wrong blockchain, i.e. based on different genesis block, different magic value,  etc.) or IP addresses of nodes running other altcoins.


Hex to ASCII conversion of output scripts generates unexpected characters

Apparently, the ASCII text is split between multiple TX output scripts, and each one is actually a multisig script with the data bytes inserted in place of the public keys.

The letters actually correspond to ASCII symbols which are the opcodes forming a multi signature script, see https://blockchain.info/tx/4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17 "Output Scripts".

Only the data between the opcodes should be treated as text if you want to decode it.


Bitcoin Transaction Fees - Want to increase fees!

There's no way to increase it unless the exchange themselves set the fee. However, as you can see here : https://jochen-hoenicke.de/queue/#24h

The Mempool is getting freed so the fees are getting lower. From my experience bittrex satoshi/byte for that 0.001 is around 400-500. Right now you can get away with 200 satoshi/byte so as long Bittrex actually send the coin immediately, it will confirm in 1-2 blocks.


Altcoin creation from bitcoin ReadBlockFromDisk: Errors in block header at CBlockDiskPos

instead of using merkel hash from the code run i used a genesis block generator to generate the hash,nounce. it took an hour to get the values using this code:

https://github.com/Gnaf/GenesisBlockZero

then i used the values from this and it worked.


https://blockchain.info/nl/charts/hash-rate

Refers to the mining power (hashrate) produced from miners and pointed towards the Bitcoin network to mine blocks.

  https://www.quandl.com/data/BCHAIN/DIFF-Bitcoin-Difficulty

Bitcoin Difficulty (diff) is a value used to show how hard is it to find a hash that will be lower than target defined by system.

Difficulty changes every 2016 blocks based on the time the network of miners took to discover 2016 previous blocks. If a block is found every 10 minutes (as it was intended initially for even emission) finding 2016 blocks will take exactly 2 weeks. If previous 2016 blocks were found in more than two weeks the difficulty will be lowered, and if they were mined faster then that it will be raised. The more (or less) time was spent on finding the previous 2016 blocks the more will difficulty be lowered (raised).

What is the maximum difficulty?

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)

Someone can argue that more the mining > more the hashrate > more the difficulty. Also the more the hashrate, the more are the investments big, the more production price of BTC increases i.e. price should keep increase to mantain BTC mining sustainable in terms of ROI.


Looking for unit testing data for Block.Bits to & from a JSON-RPC string


How does the wallet prioritise keypool addresses imported via importmulti?

There is no guarantee of the order by the API. But its currently FIFO (first in first out).

If the order/remembering is important to you, consider using fundrawtransaction with a wallet where you have private keys disabled createwallet "name" true.
Just import pubkeys define the change output address in fundrawtransaction.


just some ideas:

Strategies could be attacking the trust structure of bitcoin:

Buying large quantities of bitcoins and dropping them on the market causes it value to fluctuate and make it appear weak
hacking peer sites (like mtgox), or bitcoin users directly (via trojans, etc.) leaves insecurities on where to use it
influencing media to emphasize about the dangers of bitcoin (selling drugs, weapons, etc.) will make it less accepted in society by creating fear
creating various alternative currencies, flooding a lot of misleading information, to weaken the marketing of bitcoin by confusion and information overflow

Could be attacking the technical side:

Creating big amounts of powerful ASICS and use them for false verifications
stuffing the blockchain with spam information and useless transaction, making it to big to handle
Blocking and filtering traffic from bitcoin clients, will make it necessary to use TOR (which could be also blocked in certain ways) and will render bitcoin unusable for the average person
Switching of the internet
Brute Force attacks on the network to render it slow and unusable

Could be attacking it by legal means:

Making it illegal to use bitcoin, and tracking users via ISPs, a few show trials and people won't want to use bitcoin again (so TOR could be again an option to circumvent)
shutting down and making peer sites illegal (if they are not already, e.g. mtgox, silkroad)

Great leverage for Bitcoin will eventually come by using it via smartphones and alike, bringing the currency to the street markets. If they find a way to block these trades, they will also hurt bitcoin a lot.


How is “days destroyed” different from “amount of BTC” in existence?

Days destroyed are measured in BTC * days
Amounts of BTC are measured in BTCs

The two concepts are as different as Power (Watts) vs Energy (Joules).


Need explanation - limit buy order (Cryptopia)

When new orders are added to the orderbook, they are first matched against the most favorable existing orders. If the newly added order cannot be fully fulfilled, the remainder is put on the order book.

Your order would be limited to buying 600 coins and at a price of 105 satoshis. It would be filled after buying 600 coins. To have an order fulfill at a total amount to spend, you'd give a limit in the amount you want to spend rather than a number of coins you want to purchase. Defining all three, a number of coins to purchase, a maximum price you're willing to pay per unit and a maximum amount you're willing to pay is possible, but will not hit all three of your restrictions unless you get exactly the price you're aiming for.

In your example that would mean that your buy order would first match the sell order at 100 satoshis/coin, then match the 101 satoshis per coin and finally be exhausted by matching the 102 satoshis per coin. You'd have purchased 600 XXX at a total of 60600 satoshis.

If in your example the sell orders were each for 50 XXX, the resulting order book would look like this:

Before:
selling 50 XXX - 100 satoshis per coin
selling 50 XXX - 101 satoshis per coin
selling 50 XXX - 102 satoshis per coin
selling 50 XXX - 103 satoshis per coin
selling 50 XXX - 104 satoshis per coin
selling 50 XXX - 105 satoshis per coin
selling 50 XXX - 106 satoshis per coin
…

matching:
>selling 50 XXX - 100 satoshis per coin
>selling 50 XXX - 101 satoshis per coin
>selling 50 XXX - 102 satoshis per coin
>selling 50 XXX - 103 satoshis per coin
>selling 50 XXX - 104 satoshis per coin
>selling 50 XXX - 105 satoshis per coin
<buying 300 XXX - 105 satoshis per coin
buying 300 XXX - 105 satoshis per coin
selling 90 XXX - 106 satoshis per coin
…

After:
buying 300 XXX - 105 satoshis per coin
selling 90 XXX - 106 satoshis per coin
…

Also see: How do buy and sell orders work?


How does BTC, LTC, TRC ,etc Wallet implementations differ?

You are correct that the hex representations of the private keys and public keys are the same.

However, the difference between various cryptocurrency wallets lies in how the private keys and addresses are commonly displayed.

There is a preference for displaying private keys in "wallet import format" (WIF) and addresses in "base58check".

The first digit of these numbers is determined by what's called the "version byte".

For Bitcoin, the WIF version byte is 128 (resulting in WIF keys starting with a "5"), while the address version byte is 0 (resulting in addresses starting with a "1"). For Litecoin, these leading numbers change to "6" and "L", respectively.

Here is a table of version bytes and address prefixes: https://en.bitcoin.it/wiki/List_of_address_prefixes

And if you're interested in python code that can help you generate different types of wallets, without having to worry about version bytes, I'd check out the python library Coinkit (just "pip install coinkit").


Can the Antminer S3 mine Bitcoin using Scrypt algorithm?

No. Bitcoin does not use Scrypt, so you cannot use something that mines Scrypt to mine Bitcoin. Furthermore, the Antminer S3 is a Bitcoin miner, it can only mine SHA256d coins, such as Bitcoin. So it cannot even use the Scrypt algorithm or mine any coins that use Scrypt.


Pushpoold mmcFE-Litecoin server not running properly

To answer your questions:

This error is common, and i usually fixed after the first cronjob / first submitted share.
This error is also common, as you have not set a difficulty in the server.json file.
See this line here?

#rewrite returned 'target' to difficulty-1?
"rpc.target.rewrite" : true,

This tells the pushpoold that, if there's no difficulty set, then set it to -1, which is infinite, meaning you will NEVER find a share.

Add parameter

"rpc.target.bits" : 17

To the RPC setting section of server.json. You can change the value however you like. The higher it is, the more frequently you'll find a share. The lower it is, the hard it is to find one. This doesn't impact the ammount of LTC found.

If you're using mmcFE, be sure to edit that value in the configuration file of mmcFE.


how does node create UTXO from blockchain for the first time?

The UTXO set is updated every time a block is connected to the chain. So if you imagine during initial sync, you download block #1 and verify it, then add one UTXO to the database (the coinbase output). Block #2 gets downloaded and verified, and you add one more UTXO to the set and so on. Eventually you download block #1000 which contains a transaction that spends the coinbase output from block #1. If everything is valid, you delete that block #1 coinbase output from the UTXO set and replace it with whatever new coins are created by the transaction in block #1000.
So your assumption that "Now, I synced with it. It's time for my node to create UTXO database" is incorrect - the UTXO database is always under constant maintenance from the moment you launch bitcoind.
To start digging through the code, note this call to UpdateCoins() in the function ConnectBlock(). This will eventually call AddCoins() and you can see the UTXO are actually added to a cache first (which is eventually flushed to disk). But this is the mechanism you are looking for.
You can see where coins are removed from the UTXO cache in SpendCoin()


In case of a double spend (after double spend and prior getting resolved) what is actual account balance?

In your example, only one of the blocks will become part of the longest valid chain, and the transaction included in that block will become a part of the blockchain history. The other block would be discarded, this is what is often called an 'orphan block'.

Wallet software will show you an 'account balance', but understand this is not how the book keeping works at the protocol level. The blockchain keeps track of 'unspent outputs', which are bitcoin addresses with some as-of-yet unspent balance stored in them. A double spend is an attempt to spend a certain unspent output more than once, but ultimately the network will only accept one of those two (or more) transactions into the blockchain.

Once one of the transactions is included in the blockchain, those bitcoins now reside at a new address, and the other transaction (and any block it is included in) is dropped from the network. There is no 'double debit' from an account, so to speak. Bitcoins exist at one address, and then once a valid transaction is confirmed in the blockchain, those bitcoins exist at a new address.

I suppose some wallet software could be written to debit all unconfirmed transactions from a wallet's balance (thus allowing a 'double debit, as in your example), but this would be a naïve implementation that is not representative of what is actually happening at the protocol level.


BTC denominated vs fiat denominated stock exchange?

Advantages of BTC stock exchanges

1) Speed of deposits and withdrawals

Ordinary investors (in USA where there is no SEPA) use ACH transfers or checks to fund their brokerage accounts. ACH transfers take 3 business days and make no progress on the weekends. After this is in the brokerage account it takes another 3 days for the cash to "settle". So in an extreme case where there is a holiday weekend, a money transfer to a stock exchange (with the intent to buy stock based on new time sensitive information) on a Thursday will take

(1) Friday, (1) Saturday, (1) Sunday, (1) Holiday Monday, (2), Tuesday, (3) Wednesday, (1-Settle) Thursday , (2-Settle) Friday, (2-Settle) Saturday, (2-Settle) Sunday, (3-Settle) Monday, (Tradeable) Tuesday

On Software as a Service bitcoin denominated stock exchanges (this is also known as "centralized") this takes just a few confirmations which will average an thirty minutes (3 confirmations) to an hour (6 confirmations) to fund an account, and the bitcoin is immediately then available for trading. For trades requiring less time to profit, the user can limit exchange risk by withdrawing their bitcoin from an exchange when they are not using it, and this only takes another the time for it to confirm to their personal addresses. Using ACH transfer from a fiat exchange will again require 3 business day cash settlement time (for stock sells, derivatives have 1 business day cash settlement time) and an additional 3 business days to reach their actual bank account.

If this investor is using a check from the brokerage, the time is further compounded by an 3 business days in snail mail.

But Wire/SWIFT transfers obviously aren't much better, due to the cash settlement time before the transfer happens.

On a decentralized exchange (using mastercoin protocol, counterparty, or colored coins), one does not need to "deposit" bitcoin at all, but the sacrifice being the stock trades themselves are at the mercy of the confirmation speed, so many kinds of trading (time sensitive under 30 minutes) are not practical, but investing and swing trading is. Colored Coin protocol does not have this sacrifice. On decentralized exchanges AML is impossible barring some future invention that attempts to make some bitcoin tainted to the entire network.

2) More liquid and greater fungibility: Investment funds can be spent for goods and services, indistinct from a personal wallet's funds.

On fiat stock exchanges, brokerages create investment accounts where cash has to "settle" and be transferred to a bank account before it can be spent on goods and services. We have already established that this can take two weeks.

On bitcoin exchanges, the user's exchange addresses (accounts) are indistinct from their personal accounts. On the centralized exchanges, they function as hosted wallets, if userA wants to get paid to a bitcoin address, userB doesn't know if the requested address is being accessed on bitcoin-QT or tied to an account on a stock exchange. Similarly if userA wants to send funds from a stock exchange they can simply 'withdraw' it to userB's requested address.

On decentralized exchanges, once again the user's funds have never left their private wallet to begin with and there is no concept of withdrawing before money can be spent on goods and services.

3) Economic freedom. Invest in companies in any jurisdiction in the world, and for-profit decentralized services that have no jurisdiction.

In fiat stock markets, a company has to list in each individual market in each individual country, and investors outside of those markets/countries cannot invest. (If an investor has practical access to invest in foreign stock markets, they are not your ordinary investor). Also many markets and countries have capital controls as well as socioeconomic barriers to entry.

In bitcoin stock exchanges, these barriers do not exist. If you want to invest in a hot sector in Gangzhou China or Missouri USA, you can just do that. On centralized exchanges, site operators have at some points attempted to limit people from certain countries (america) from accessing their markets, due to liability issues. With decentralized exchanges there is no practical way to limit access in this way.

4) Low to nonexistent costs to listing a company.
Many more types of crowdfunding can take place since hundreds of thousands of dollars in legals fees are not necessary to create an asset for trading.

5) Smaller investors can invest.
In fiat stock exchanges, minimum funding requirements can be $2,000 for a margin account or minimum account size at all. Its fun to tell teenagers to invest $100 a week in a stock so they'll be rich by the time they are 50, but no decent brokerage will let them open an account, and they'll be better off trading Nike shoes and go on to other frivolous activities.

In bitcoin stock exchanges this doesn't exist. Some centralized exchanges have high fees to enter, decentralized exchanges cannot barring a future protocol that does.

6) Lower fees to trade.
centralized exchanges have their own trading fees. decentralized exchanges will only have the network fee and whatever their protocol requires.

fiat stock market fees can be much higher, at 'discount brokerages', in direct access markets, and in tailored investment firms (bucket shops)

7) Data feeds are not delayed, free
Fiat stock markets give delayed data unless the investor goes out of their way to find better and better data with more and more custom tailored services. It is only a fairly recent change that an individual investor can get live quotes across exchanges at all, let alone level 2 order book information. But even then, this investor has to do a lot of research to find ways to do this cheaply.

No bitcoin stock exchange delays data. This would actually be hard to do. This is impossible on decentralized exchanges and no centralized exchange would gain a community if they did that.

8) Free API access
In fiat stock markets, getting API access to data feeds is impossible or very expensive. Nasdaq charges $6,000 a month for this access, and the protocol (FIX) is very antiquated compared to JSON and restful services.

Bitcoin stock exchanges all user modern JSON, some use various forms of restful services and Oauth. All provide this for free, not as a courtesy but because that is modern and the data is there.

Now ordinary investors are able to both VIEW live data and retrieve it via API for their own applications.

With fiat stock exchanges, making trading applications such as automated bots were largely out of reach for ordinary investors due to the restrictions in data access, contributing to an illusion that "High Frequency Trading" was an unattainable mystical trade reserved for the mystical quantitative programmers in secretive hedge funds.

9) 24/7 market hours

Bitcoin stock exchanges never close. Trade any asset any hour of the day. There are no gap ups and gap downs due to information coming out while markets were closed.

This is an advantage because information can become available at any time for a security in any part of the world.

In centralized exchanges, implementing "closed" hours is difficult (but a future exchange may opt to do this), and in decentralized exchanges this is impossible barring some future protocol change.

Advantage of fiat stock exchanges

1) Margin, lots and lots of margin. bitcoin currently does not have a practical way to offer margin for stocks.

2) SIPC insurance, for stocks. If the exchange shuts down many regulatory environments have a way for depositors to get their money back up to a point.


Coins sent to unknown address in Multibit

(I am one of the MultiBit devs).

The MultiBit code is hosted on multibit.org ONLY.
The 'tv' copy is a phishing site.

DO NOT USE IT.


Not sure if you're still looking for an answer, but I just stumbled upon this myself and for the benefit of anyone running into this.

Even though it's called cookie based authentication, you still authenticate via Basic HTTP.

Let's say your cookie was __cookie__:somerandomlongstring then:

Username __cookie__
Password somerandomlongstring

I figured this out after finding this comment on Github


Blockchain.info returns "None Standard Script Output" when submitting a transaction?

There is nothing wrong with this transaction, the website you tried to submit it through (blockchain.info) is defective. I have broadcast it for you, and it is visible as a confirmed transaction on most block explorers.

bitcoin-cli decoderawtransaction is a useful tool which will let you decode and view the transaction have created prior to submitting it to the network, and bitcoin-cli sendrawtransaction will allow you to broadcast the transaction without relying on possibly faulty third parties.

{
  "txid": "63913178feb485db6f25c9f7940e3d17175ae7a51bf1ae58acf8f11ee95a2966",
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "f713e91b7df1dc4e4e85c7e2d9a050ca95408d1f578925f54aa93dc7bc98daa7",
      "vout": 0,
      "scriptSig": {
        "asm": "3044022012051ad672731cf555964c23d31defb67b06a85ea7de4843777d7058d3a084490220567864bf79669a8cb48e8de29f31fb29caef56f741ab9145424b3430af7b317001 038042cf5da3747c559e1d77e574eb81842958ef0cbc0461c1b783eda091afa782",
        "hex": "473044022012051ad672731cf555964c23d31defb67b06a85ea7de4843777d7058d3a084490220567864bf79669a8cb48e8de29f31fb29caef56f741ab9145424b3430af7b31700121038042cf5da3747c559e1d77e574eb81842958ef0cbc0461c1b783eda091afa782"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 1701669232",
        "hex": "6a0470696d65",
        "type": "nulldata"
      }
    },
...
}


Is there a listing of strange or unusual scripts found in transactions?

Blockchain Info has a list of strange transactions that its nodes received but were unable to verify.


The 2015 stress test aimed to hit 200MB of backlogged tx, they only hit 15MB as reported by coindesk.

Blockchain.info reports that the backlog of tx hit 120MB May 16th 2017. It's mostly been above 20MB for the last 60 days as of this post.

How big of a stress test is big enough for you?


Is it ok and safe to import master public key from electrum wallet into bluewallet to be a watch-only wallet?

Is it safe to do so?

It should be considered safe. For better privacy and security, using your own Electrum server in Bluewallet could also help. Creating transactions in a watch-only wallet using bluewallet and signing them using Electrum offline has no issues.

Is there any better way to do it so I don't have to send the unsigned and signed transaction back and forth?

After signing the transaction you can broadcast it from anywhere. For example: I can sign it on a mobile device which is not connected to Internet but can send text messages, can encode transaction hex and broadcast it using text messages. Related Q&A
Or you can broadcast transaction using this link in Tor browser on an online device: http://explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion/nojs/tx/push but you will have to copy the transaction hex after signing or maybe just scan QR code.
FullyNoded is also a good project that you may find interesting considering you have an iPhone.


I wrote a solution to this problem two days ago:

How to use p2pool with an accompanying standalone bitcoind

(since the windows gui version of bitcoin 0.5.1 crashes frequently when used with p2pool)

Assumptions:

OS: Windows 7

Bitcoin: Latest stable release installed and working - http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/bitcoin-0.5.1-win32-setup.exe/download

p2pool: you'll be slightly off the beaten path with this
   configuration as you're specifying the bitcoin address to send
   generated bitcoins and not using the second bitcoin processes wallet

Download latest current p2pool code and extract to
"%programfiles%\p2pool" -
https://github.com/forrestv/p2pool/zipball/master
Download and install latest Python 2.7 (if you get 64bit, you'll need
64bit versions of the packages below) -
http://www.python.org/download/
Download and install python extension package twisted -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#twisted
Download and install python extension package zope.interface -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#zope.interface
Download and install python extension package pil -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil
Download and install python extension package pygame -
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil
Open your Bitcoin GUI client if it is not running and generate a new
address, take note of the generated address and close your Bitcoin
GUI client
Edit your existing "%appdata%\bitcoin\bitcoin.conf" and unless you
know what you're doing, change what ever is there to this and if the
file does not exist - create it:

logtimestamps=1

Create the folder "%programfiles%\p2pool\bitcoind-data"
Create "%programfiles%\p2pool\bitcoind-data\bitcoin.conf" with your
 favorite text editor and populate it with this:

server=1
logtimestamps=1
port=18333
rpcport=18332
rpcuser=bitcoinusername
rpcpassword=bitcoinpassword
rpcallowip=*

Take note of the folder name of the latest current p2pool code - it
 is in "%programfiles%\p2pool"
Create "%programfiles%\p2pool\p2pool.cmd" with your favorite text
 editor and populate it with this:

@echo off
title p2pool
echo.
echo running p2pool ...
echo.
C:\Python27\python.exe "%programfiles%\p2pool\folder-name-of-the-latest-current-p2pool-code\run_p2pool.py" --net bitcoin --address yourbitcoinaddresshere --bitcoind-address 127.0.0.1 --bitcoind-rpc-port 18332 --bitcoind-p2p-port 18333 bitcoinusername bitcoinpassword
echo.
echo p2pool stopped.
echo.
pause

eg.

@echo off
title p2pool
echo.
echo running p2pool ...
echo.
C:\Python27\python.exe "%programfiles%\p2pool\forrestv-p2pool-4f6c2e2\run_p2pool.py" --net bitcoin --address 12uN6G1uAtn7G29qfTdLD9des4y63Whr61 --bitcoind-address 127.0.0.1 --bitcoind-rpc-port 18332 --bitcoind-p2p-port 18333 bitcoinusername bitcoinpassword
echo.
echo p2pool stopped.
echo.
pause

Create "%programfiles%\p2pool\bitcoind.cmd" with your favorite text
editor and populate it with this:

@echo off
title bitcoind
echo.
if exist "%programfiles%\bitcoin\daemon\bitcoind.exe" (set programfilesx86=0)
if exist "%programfiles(x86)%\bitcoin\daemon\bitcoind.exe" (set programfilesx86=1)
if %programfilesx86%==0 (goto :programfiles)
if %programfilesx86%==1 (goto :programfilesx86)
echo ERROR! bitcoind.exe not found in either "%programfiles%\bitcoin\daemon\" or "%programfiles(x86)%\bitcoin\daemon\" - giving up!
echo.
pause
goto:eof
:programfiles
echo running bitcoind.exe from "%programfiles%\Bitcoin\daemon\" ...
"%programfiles%\Bitcoin\daemon\bitcoind.exe" -datadir="%programfiles%\p2pool\bitcoind-data"
echo.
echo bitcoind stopped.
echo.
pause
goto:eof
:programfilesx86
echo running bitcoind.exe from "%programfiles(x86)%\Bitcoin\daemon\" ...
"%programfiles(x86)%\Bitcoin\daemon\bitcoind.exe" -datadir="%programfiles%\p2pool\bitcoind-data"
echo.
echo bitcoind stopped.
echo.
pause

List item
Copy blk*.dat from %appdata%\bitcoin to
 %programfiles%\p2pool\bitcoind-data

Run "%programfiles%\p2pool\bitcoind.cmd"
Run "%programfiles%\p2pool\p2pool.cmd"

You should now be able to mine on your machine to 127.0.0.1:9332 or to your machines IP on port 9332 on your LAN :)


Byzantine fault-tolerant consensus - Why 33% threshold

We have a mathematical proof that to tolerate n malicious nodes, you need 2n + 1 good nodes. The full proof is found in G. Bracha and T. Rabin, Optimal Asynchronous Byzantine Agreement, TR#92-15, Computer Science Department, Hebrew University. It's also well known in the industry. It is not possible for an asynchronous system to provide both safety (the guarantee that all non-malicious nodes will eventually agree on what progress was made) and liveness (the ability to continue to make forward progress) with more than this number of malicious failures.

You can trivially ensure safety by simply making no forward progress at all. And you can trivially make forward progress unsafely by just letting each node do whatever they want. Neither of these modes of operation are useful.

Let's take a step back to make this answer more helpful:

Why do you need a distributed agreement algorithm at all? Well, you need one in cases where there is more than one way a system could validly make forward progress and you need all the participants in the system to agree on which one of them.

Consider a simple example: I have $10 in the bank, and I write two $10 checks, one to Alice and one to Bob. Either one alone is valid, but we can't let them both go through.

If we had a central authority, they could just clear whichever one they saw first. But what if we don't want a central authority or don't want a single point of failure? And what if we have potentially malicious participants?

Well, you could just sort the checks after representing them as binary data. But that's where the asynchronous component bites us. When do we sort them? Say I see both checks and sort them. How do I know that one second later I won't see a third check that sorts first? And maybe someone else already saw that one. Ouch!

So, we have the following requirements:

1) Our system is asynchronous.

2) Some participants may be malicious.

3) We want safety, that is, we do not want one honest participant honoring one check and one honest participant honoring the other.

4) We want liveness, that is, it's not fair just saying we never clear any checks. Sure, that's safe, but not useful. We want to be sure that we eventually agree on which checks to clear.

So, now the question arises -- how many dishonest partcipants can we tolerate in our asynchronous system and still guarantee both safety and liveness?

As a simple way to get the gist of the proof, though it is not rigorous:

Suppose we have n nodes of which h are honest and d are dishonest. Obviously, n = h + d. Now the system needs to come to consensus on which of two checks to clear.

Think about the case where all the honest nodes are evenly split about the two directions the system could make forward progress. The malicious nodes could tell all the honest nodes that they agree with them. That would give h/2 + d nodes agreeing on each of two conflicting ways the system could make forward progress.

In this case, the honest nodes must not make forward progress or they will go in different directions, losing safety. Thus, the number of nodes required to agree before we can make forward progress must be greater than half the number of honest nodes plus the number of malicious nodes, or we lose safety.

If we call t the threshold required to make forward progress, that gives us: t > (h/2) + d. This is the requirement for safety.

But the malicious nodes could also fail to agree at all. So the number of nodes required to agree before we can make forward progress must be no more than the number of honest nodes or we lose liveness.

This gives us t <= h. Or h >= t. This is the condition for liveness.

Combining the two results, we get:

h >= t > (h/2) + d
h > (h/2) + d
(h/2) > d
d < (h/2)

Thus the number of faulty nodes we can tolerate is less than half the number of honest nodes. Thus we cannot tolerate 1/3 or more of the nodes being dishonest or we lose either safety or liveness.


Relation between bitadress and blockchain

how does the blockchain.com/explorer page know if an address is included in a wallet?

Short answer: it doesn't.
Blockchain.com just looks to see if it has a record of a transaction involving the address you give it.
A transaction is something such as a bitcoin-exchange sending you Bitcoin (after you sent them dollars) or you sending Bitcoin to someone else (e.g. when buying something with Bitcoin)
Details of Bitcoin transactions are public information and are copied to every Bitcoin user (or are available to every Bitcoin user).
But you don't need to use bitaddress.org or any similar service and I wouldn't!

A little more detail.
The web-page at Bitaddress.org uses a pseudo-random number generator based on mouse movements and keyboard input to generate a random private-key.
From a private-key you can derive a public-key. The Bitcoin-address is a hash of the public-key.
The private-key enables you to spend Bitcoin and should never be shared with anyone else.
The public-key enables other people to send you Bitcoin, you give them the address derived from the public key.
There need be no link between bitaddress.org and any blockchain explorer. The latter just searches the blockchain for transactions involving the address you type in.
The blockchain is a ledger (or more accurately a journal) containing a record of all bitcoin transactions from the creation of Bitcoin 10 years ago. All "full-node" wallets have their own copy of the whole blockchain.

Don't trust websites
Despite the above, I would not use a public service like bitaddress.org to create my private-key. After all, we don't know if the owner of that website dishonestly keeps the private-keys (or has been hacked). Bitcoin was originally designed to be used without trusting third-party services like this. You can download a desktop-wallet and generate your private-key in the privacy of your own home on a computer that is disconnected from the Internet. That is the one of the safest ways to inexpensively create a Bitcoin wallet.

Never let anyone else generate, use, borrow or see your private-key
Never share the password to your wallet, even if you change it afterwards it is useless to do so because they can already have copied your private-key - which they can later use outside your wallet to spend any  Bitcoin you later added to that wallet.
If you do not understand Bitcoin adequately you may lose all your money.
If you trust websites, you may lose all your money.
If you are not careful about these things you will lose all your money.


[is] there anyway to tell which exchange it went to

In general it isn't possible.

i do have the original wallet numbers

Wallet numbers aren't really a thing, there are wallet-IDs for some custodial wallets and there are Bitcoin-addresses for normal wallets.
If the number has hyphens in it, that might be a Wallet ID for an account at blockchain.com. In which case their support might be able to help.
If the number looks like a Bitcoin address, it isn't generally possible to trace those anywhere useful and you can't recover control from an address alone.
There are specialist businesses that perform blockchain analysis to try to infer relationships between addresses and to infer ownership of addresses. They are probably expensive to use and probably do not find anything useful in most cases.
It may be better to look for email or other text messages relating to a possible custodial account.


This sounds good, in broad strokes.  There are a couple of things I would watch out for:

Refunds can be tricky.  People who are using web wallets may not really have their own addresses; the wallet operator has a large pool of addresses and tracks customer balances internally.  When the customer wants to make a payment, the operator pays from one of the pool addresses and debits the customer's account.  So if you try to send a refund to such a customer, it goes back to the operator's address, but they may not have the ability / motivation to recredit the customer.  They might even throw away the private key once the coins are spent (and the change sent to a new pool address), in which case the refunded coins are lost forever.  Either way, the customer is bummed.  There is some further information at Is there a standard procedure for refunding Bitcoin transactions?, and BIP 70 is a proposed solution (where the customer provides a separate refund address explicitly), but since this involves some out-of-band messages over HTTPS, more infrastructure is needed on the server side.
You may want to give up on delivering the product after 2 minutes, but you might not want to give up on the payment.  For example, if either your machine or the customer's mobile device has Internet connectivity problems, the payment might be created but not broadcast (or not received by you) until much later.  The customer is probably no longer there to get their can of Tab, but you might want to refund their money anyway.  So you should keep the private key around.  (Actually, there's really no good reason to discard them: if you send the money back to HQ, they normally contain no coins so it's not really a problem if they are stolen, but if somebody sends extra coins to them for some reason, you'd sure like to have them.)
Similarly, if you do send a refund, you may want to make sure you spend the same transaction that came in.  This will protect you in case the customer tries to double-spend.
The payment amount can be embedded in the QR code.  This saves the customer a little typing.
Quickly sending incoming payments off to HQ for safekeeping is a good idea, but will cost you a fee on each transaction.  You could batch them and send them off a couple times a day, or whenever they reach some threshold amount.  Alternatively, you could have a system where you generate a bunch of addresses at HQ, keep the private keys there (perhaps even offline), and just give the machine the addresses.  (BIP 32 provides a fancier way to achieve that.)  The machine can still detect incoming payments, but if a refund is needed, it would have to send a request back to HQ.


How to create a p2sh transaction with a scriptsig of OP_true?

Here you have an example of a transaction spending from a P2PKH output and creating a P2SH output with an OP_1.
And here you have the counterpart, a transaction spending from the first one (with an input script '0151') and generating a P2PKH output.
I've created both using a Python library i'm coauthor of. You can check it out here.


Would this scheme allow faster verification of transactions? (Multiple parallel block chains)

I'm not sure this is the right forum for this sort of discussion, but I'm not a mod.

Anyways, decreasing the transactions in a chain does nothing to make block creation faster.  That is a hard-coded target in the code.  If the hashing power goes down, the difficulty goes down, and it all balances back at 10 minutes.  There's no benefit in terms of confirmation speed from your proposal.

Total hashing power is also a big factor of overall security.  With your proposal, instead of 1 chain with with hashing power of X, you have N chains each with hashing power of X/N.  It means that the cost to attack a single chain with a 51% attack decreases by a factor of N.  That's not good.

This also does nothing to solve the problem of centralization of mining power.  Big mining pools will simply diversify their hashing power across all N chains, giving them the same proportional control they currently have.  No benefit there.

Given the complexity that will be required to re-sync the chains, and not really getting any benefit from it, I would say that this idea would not work.

I think you may be interested in a similar concept called sidechains.  You should give that a read, since it might be what you are after.  If you are more interested in instant transactions, I think you would find the Lightning Network interesting.