How Bitcoin wallets and it's transfer process work?

First, a wallet is a software application that usually manages your keys, addresses, and transactions. When someone sends you Bitcoin, it is generally sent to one of the addresses that the wallet software manages. There really is no limit to how many wallet software applications you can run, and not really a limit on addresses either (except for disk space, but that's not really a concern etc.).

Your wallet software should allow you to create new addresses that you can use to receive Bitcoin.

Exchanges work by managing your Bitcoin in their internal wallet software, and you exchange anonymously with others by placing and filling orders on the global order book. The exchange manages the Fiat (dollars) currency exchange internally as sort of an escrow.


Which Venture Capital firms are especially interested in Bitcoin?

There hasn't been a definitive survey of the venture Capital industry but Boost VC has made several bitcoin investments. Its founders Adam Draper and Brayton Williams are responsible for organizing the Boost Bitcoin Fund which several venture capital firms are participating in. There are also currently 7 bitcoin companies in their 2013 class of startups.


How to generate a payment request [BIP70] with specified fees

BIP 70 does not allow the merchant to specify the transaction fees to be used.


Yes, it's generally part of the scriptSig.

More specifically, it's part of the signature pushed by the script.

Most specifically, it's the last byte of the signature.


How to add an address to a CheckLockTimeValue (CLTV) transaction output using bitcore-lib (or any other js lib)

You're putting a script directly in the scriptPubKey. That's both discouraged, non-standard, and hard to use, as you've noticed there is no corresponding address.

There are only three types of addresses defined (with common acceptance) in Bitcoin: base58-encoded P2PKH addresses (1...), base58-encoded P2SH addresses (3...), and bech32-encoded native segwit addresses (bc1...). Unless the output you want to construct has the structure corresponding to one of these, there simply does not exist any address for it.

This is with good reason: when you give an address to someone else to pay you, they have no business knowing how you want to protect your coins. As the policy you want to use gets more complex, sending to more and more complicated scripts would require them also to pay increasing fee. This is weird: it's you who cares about that policy, so you should pay for it instead.

With P2SH (and later P2WSH), the script is no longer put in the output itself. Instead, a hash of the script is put in the output, and the recipient, when spending the output reveals what the actual script was and satisfies it.

So you probably want to either do this manually by reading how to construct a P2SH/P2WSH output (see BIP16 and BIP141 respectively), or figure out how the library you're using lets you construct such outputs automatically.


This is a known bug in the early days of bitcoin.

Was fixed by BIP-30 https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki

There is a discussion here: https://bitcointalk.org/index.php?topic=216938

And yes, 50+50 bitcoins are missed forever.

In fact, there are much more missed bitcoins. For example, 2500 bitcoins were gone to nowhere
in block 0000000000000449ee5b94ba7a051caffff5c23d6a03335f6e20e3985b5ffa61


Why am I receiving an email from Blockchain about receiving a payment?

You aren't. It just looks that way, superficially.

received an email from Blockchain

It is easy to fake the "from" address in an email.
If your email app lets you view the full raw email headers you can probably see that this email followed an unusual path to reach you. But you don't need to do this. Businesses like Blockchain don't send emails to people who are not already their customers.

Authorize 3 network confirmations to add incoming 3.86655869 BTC to your Bitcoin balance.
What does this mean?

It is nonsense. It looks like a phishing email where someone is attempting to trick you into some sort of scam. Either getting you to divulge account details which will allow them to steal money or getting you roped into some kind of advance-fee fraud where they persuade you to pay them a release-fee or some other invented nonsense that is plausible to the inexperienced.
I would delete that email and forget about it.


Does bitcoin stop periodically for finalising the next block?

No, block discovery is a memory-less process. Every try of discovering a valid block is completely independent from any other. Miners continuously search for a new block. The only thing that changes over time is which transactions they're trying to include and what preceding block they are building on-top of.

When some miner finds a block that fulfills the required criteria, they just publish it to the network. The propagation of the new block also works as the signal for all miners to switch work to a successor of this block instead of the predecessor.

Transactions are relayed in the network independently and continuously. Miners may update their block template to include new juicy transactions every once in a while, but it's up to them how often and when they do this.


You are signing a specially modified version of the transaction itself. The modified transaction involves replacing the scriptSig field temporarily with the scriptPubKey from the transaction output being spent, and leaving all other inputs' scriptSigs empty, and then appending a 4 byte signature type code. The transaction is then hashed twice with SHA256 and the final hash is signed.

See this question for more info: How to redeem a basic Tx?


I lost my 12 or 24 words to my bitcoin wallet. I just have my password

Sadly if you lost your seed phrase (12 or 24 words) you won't be able to regenerate your private key and get your funds control back. Best advice, look harder where you wrote it or stored it.
PS. Never write your seed phrase in any online place or take any picture, just piece of paper very well stored.


Mitigating a Double Spend Attack by Punishing the Attacker?

Given two transactions that spend the same input, there is no way to know which one 'came first' or is the 'rightful' transaction. Because of this, it is very difficult to enforce a 'no double spend' policy in this way. How can you guarantee that you have the transactions ordered correctly? What happens if some nodes on the network see the transactions arrive in a different order? Or what if a scammer sends a payment, but then claims that a transaction that pays those same coins back to themselves is actually the 'first' transaction? Etc.
This is why the blockchain exists in the first place: to give an explicit order to the transactions which occur on the network. Attempts to make 'zero-confirmation transactions' as reliable as confirmed transactions will never succeed, and if they could, then we could just do away with the whole blockchain! Perhaps there are ways to make double-spend attempts less likely to be successful, but ultimately if you are accepting zero-confirmation transactions, then you are incurring some risk of being double spent against.

For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we "burn" (or destroy) the locked up BTC.

You have more or less described an escrow system, in which a third party is employed to ensure that the transaction in question proceed smoothly. This is possible today, and indeed some markets provide access to this sort of protocol.
Keep in mind: if you are requiring that the user lock up some coins on-chain as collateral... that will require a bitcoin transaction to create this 'locked up UTXO'. To create that UTXO you will have to wait for an on-chain transaction to confirm... and at that point you might as well just wait for the payment to confirm in the first place! If you don't wait for it to confirm then you're just back at square one in regards to double-spend risk.
Attempting to automate this doesn't seem viable, for reasons similar to those I mentioned in the first paragraph above.


Number of bitcoind peers drops precipitously every 30 days or so

Being doing my own diagnosis on this issue. I have bitcoind and lnd running on the same raspberry pi, as per the excellent Raspibolt guide by Staticus. I wrote the following script to log both daemons' cpu usage, mem usage and total number of bitcoind peers:
#!/bin/bash
echo \
"$(date +%D,%T),"\
"$(ps -U satoshi -o comm= -o %cpu= | grep bitcoind | awk '{print $2}'),"\
"$(ps -U satoshi -o comm= -o %mem= | grep bitcoind | awk '{print $2}'),"\
"$(ps -U satoshi -o comm= -o %cpu= | grep lnd | awk '{print $2}'),"\
"$(ps -U satoshi -o comm= -o %mem= | grep lnd | awk '{print $2}'),"\
"$(/usr/local/bin/bitcoin-cli -conf=/etc/bitcoin.conf getconnectioncount)" >> /home/satoshi/bitcoin_connections

My issue may be simply allowing too many connections to my daemon. As peer count grows, mem usage does as well. When it gets to 130+ peers total system memory usage is >80%. My issue may simply be an issue with running out of memory. I'll edit this post when I have more results.
Edit:
It seems that as I get to around 120-130 peers the combined mem usage of bitcoind and lnd exceed 60% of the 1 gig on my RPi, pushing total mem usage over 90%. At that point peer count drops off. I presume the daemon starts to respond very slowly as memory runs out and other peers drop mine. I set maxconnections=125 (default) and the daemon has run for weeks without issues. Since 125 is the default, the same result could be achieved by commenting out the maxconnections line in bitcoin.conf completely.


What does the little-endian notation improve for Bitcoin?

Almost all CPUs these days work natively in little-endian. To operate on big-endian numbers, additional byteswap instructions are needed.
For most things, I think this effect is negligible. Network protocols need a convention to represent things, and Bitcoin's creator picked one. The actual choice barely matters.


The most common pronunciation I have heard is /skript/


One way is to buy the bitcoin with fiat (cash) through localbitcoins.com (find a seller with at least a few transactions and 100% reputation). Have the bitcoin fraction you are buying delivered by the seller to the address you want. Just be very sure to get the address correct. You can verify that the funds reached the address by checking on any bitcoin block explorer, such as blockchain.info.  Once you verify the bitcoins are the address you want, you can pay the seller.


Attaching additional data / text message to a Bitcoin transaction?

The obvious solution would be to require payments to have an OP_RETURN output with an email address encrypted to you. This isn't simple and there isn't a wallet out there that supports something like that, but it's technically feasible.

For the 1 address problem, you can use a deterministic wallet, which can generate as many addresses as you need. You can use BIP47 if you want to get fancy and be able to offer refunds.

I built a web shop example app for Armory a while back that you might want to look at that generates a new address for any transaction. You may want to take a look:

https://github.com/etotheipi/BitcoinArmory/tree/master/webshop


What is the difference between policy and consensus when it comes to a Bitcoin Core node validating scripts?

The term "consensus checks" refers to the rules that determine whether a block is valid; specifically, if a consensus check on a block (or a transaction contained within a block) fails, then the block is considered invalid.  If we get to the end of the block and none of the consensus checks has failed, then the block is valid.
Policy checks are a superset of consensus checks (meaning that policy checks are in addition to consensus checks, so that passing policy checks implies passing consensus checks), and policy checks only apply to transactions that are being considered for addition to the mempool. The purpose of policy checks is generally to (a) close off DoS vectors and (b) to make future consensus changes safer to deploy, by preventing relay of transactions that would violate such future consensus changes well in advance.
You're specifically asking about transaction script checks, but note that there are many policy (and consensus) checks on transactions that occur outside of just script validation.  Also, the links in your question are to the "policy/" and "consensus/" subdirectories in Bitcoin Core's source tree, but there are many policy and consensus checks that happen outside of those directories.
Here are some examples of policy checks in script validation, that are not (yet) consensus checks. These first ones are from BIP62, which proposed a set of rules to limit transaction malleability.

STRICTENC
LOW_S
SIG_PUSHONLY
MINIMALDATA
CLEANSTACK

Here are some policy checks relating to making softfork deployment safe in the future:

DISCOURAGE_UPGRADABLE_NOPS
DISCOURAGE_UPGRADABLE_WITNESS

There are some miscellaneous other policy script checks, such as requiring that all pubkeys in segwit scripts be compressed, or that inputs to OP_IF/OP_NOTIF be minimally encoded. And then of course all future consensus changes (such as Taproot changes) that have not yet been activated on the network are policy checks as well. An (almost) full list of what transaction script validation checks are performed as part of policy checks when a transaction is being validated for the mempool can be found here. (Note that this list includes consensus checks as well.)
However that is not quite a complete set of transaction script validation rules that are enforced as policy checks. During mempool acceptance, we perform other checks on a transaction as well, some of which depend on a transaction's scripts. Some examples of these include:

Non-p2sh, non-segwit spends must be P2PKH, P2PK, or bare multisig
scriptSig or witness must be no more than a given size
Various rules on outputs created (no more than one OP_RETURN, must be P2SH/v0 segwit/P2PKH/P2PK/MULTISIG, value must be above dust threshold)
Limits on how many signature checks are performed by the transaction

There are a lot of these to list, but tracing the code in mempool acceptance (particularly here) and inspecting functions like CheckTransaction, IsStandardTx, and CheckTxInputs should yield the remaining policy script checks, on top of the ones enforced inside the script interpreter.
Transaction script consensus checks are a much smaller set. Some of the script flags that are now consensus checks include:

P2SH
DERSIG
NULLDUMMY
CHECKLOCKTIMEVERIFY
CHECKSEQUENCEVERIFY
WITNESS

The full list (with enabling conditions) can be seen here. Note that as consensus rules have changed in Bitcoin's history, not all the script flags mentioned in that function are enabled on all blocks.
Most (all?) of the remaining consensus checks performed on transactions can be found in ConnectBlock(), CheckBlock(), and ContextualCheckBlock().


Will a Litecoin LTC transaction with a low fee of .001 confirm?

I have seen transactions with 0.000224 fee are also getting confirmed.

So we can say 0.001 LTC fee is too good.

You can check current fee here

https://bitinfocharts.com/comparison/litecoin-median_transaction_fee.html#3m


Import/Export wallet vi bitcoin-cli. Bitcoin abc node

importwallet is the opposite RPC of dumpwallet, not backupwallet.

backupwallet creates a copy of your wallet.dat file. You restore that file by putting it back in the data directory.

dumpwallet creates a wallet dump (just private keys, no history, addresses, labels, accounts, ...), which can be imported into an existing wallet using importwallet.


PHP script to create private key & public address

I enjoy using this package :

Uniform Server Key Generator

And with it running, you can just execute : openssl_pkey_new(); to generate a private/public key set.


End-user security measures to protect your Bitcoins

Most Bitcoin thefts occurs due to user careless and ignorance, like not using two-factor authentication and sharing email and password across questionable websites. The risk of theft can be easily reduced by taking the basic security measurements which you should follow in any case when you are dealing with Internet.

Here are some things you should include in your presentation

Don't use questionable Bitcoin services or exchanges (see: Mt.Gox) - if you are unsure ask the Bitcoin community about the integrity of the service. Any "free bitcoins" sites are definitely no go.
Always enable two-factor authentication when using Bitcoin services (exchanges, web wallets)
Keep most of your Bitcoins in a cold wallet or vault service which is not directly connected to Internet
Don't install unnecessary software on the computer you use to handle Bitcoins. Especially don't install software from download sites (even legit ones) or from Bittorrent. Always download software directly from the site of the author.
Don't install unnecessary browser extensions
Don't use the same computer to surf on questionable sites (adult entertainment, illegal software, tor) - you usually get malware infection from sites like this
Keep your computer software up-to-date
Don't click phishing links
To reduce the risk of malware, use safer operating systems like OSX or Linux instead of Microsoft Windows. Please note that this only lowers the malware risk, it doesn't guarantee immunity if you don't follow the other advices mentioned here.

More information about Bitcoin end user threats can be found in this question.


how is Proof of Burn policed to prevent simultaneous buying into multiple alt currencies?

One approach to proof of burn is that you burn coins by sending them to a particular address specified by the altcoin.  For instance, with Counterparty, you could collect XCP by sending bitcoins to the "burn address" 1CounterpartyXXXXXXXXXXXXXXXUWLpVr, thus making the bitcoins unspendable.  Presumably no other altcoin is going to choose that particular address as their burn address, so there is no way you could earn any other currency by burning coins in that manner.

Of course, someone could have started another currency (call it PDQ) that awards credit for coins burned to the Counterparty address, and then people sending coins to the Counterparty address would earn both XCP and PDQ.  I don't know of any reason why anybody would want to do that, or why anyone should expect the hypothetical PDQ currency to pick up any value.

Your reference to "double spend" suggests something different: that you might try to send bitcoins to the burn address for some altcoin, collect your altcoin reward, and then use a double-spend attack to reverse your burn transaction and keep the bitcoins after all (perhaps later burning them for a second altcoin).  As Andrew Chow says, the first altcoin should prevent this by waiting to award the altcoins until the bitcoin transaction has sufficiently many confirmations.


If you are using bitcoin core, you can try to erase the transactions in your wallet.dat file with pywallet. (https://github.com/jackjack-jj/pywallet)

Then you only have the keys left in your wallet.dat. When you start Bitcoin, you'll need to start it with CLI and add the option -rescan.

Your BTC should appear in your balance as unspent. You can then send them again, with a higher fee. When that transaction will confirm, the old one will automatically be rejected because it'll be a double spend.

But in the end, it makes you able to send your BTC again. :)

REMEMBER : ALWAYS BACKUP YOUR WALLET.DAT FILE BEFORE DOING ANYTHING !


Check which C-Lightning version I am running?

Sure, just use:

$ lightning-cli --version
v0.6-127-gf8fa421


How to check if an output has been spent?

If gettxout returns something, the output is unspent. If it returns nothing, the output either never existed or is spent.

You do not need -txindex for this.


That would be best left to contacting the support of the online wallet.  Most online wallets use that kind of login and usually have a link for support.


Why we must reference the entire txid for each output we want to spend?

By compressing the txids to a shorter fingerprint, you're reducing the unique identifiability. For example, there are three transactions that match the prefix eb36eca: tx1, tx2, tx3.

So, essentially, this is creating a combinatorics puzzle, especially considering that the txid is only part of the outpoint, you also have to add the output, otherwise you could be referring e.g. to any of the 51 outputs of the above tx3.

It seems to me that this would make it more complicated to operate thin clients safely, which don't have the complete UTXO Set at their disposal. For relay, similar compressions are already used, but while a such a system might be possible to implement for blockchain data, I'm not sure if the overall effect would be desirable.


If you did not send the Bitcoin's then someone has access to your account or private key. This could happen many ways, if you have ever shared your login details with anyone or, your backup seed, logged in through internet cafe's or strange computers or if your phone or computer are hacked to name a few possibilities.


sorry there is no documentation.

The console application QbitNinja.Console.Listener is an app which connect to a trusted full node and push the data into Azure Storage. Due to latency, you should run that on a VM hosted in azure in the same region as your storage.

The website can be deployed as a Azure Web App, it only query the data indexed by the Listener.

If you have basic knowledge in ASP.NET and Azure, this is easy to setup. If you do not have, I advise you to start by learning about how to deploy a web app on azure.


Can I send bitcoins straight from an ATM to a vendor?

I think it is best to transfer to a wallet you control first.

This gives you full control of the transaction you send to make payment tp the vendor. This may be important in some situations. For example:

When a vendor gives you a payment address, it may come with a condition of sending payment within a certain amount of time (1 hour, for example). If you buy from an ATM, the ATM operator may only send a transaction to pay all customers once every couple of hours. So if you try to pay the vendor directly from the ATM, the vendor's payment page might time out by the time the payment is confirmed. In that case, you'd probably have to contact their customer service to resolve your order.


Even on testnet the difficulty is sufficiently high that it will take you a long time to mine anything using cpu. (Lots of people testing ASICs, presumably.)

Your best bet is probably Testnet in a box. Then you can cpu mine just by using ´setgenerate true´ in Bitcoin Core.


Where can I find a step by step tutorial on how to setup primeminer and join a pool?

Probably, you are looking for this: http://www.peercointalk.org/index.php?topic=798.0

www.peercointalk.org - is a official forum of ppcoin and primecoin.

Short instruction for Ubuntu 13.10 Saucy Salamander x64:

# Update & upgrade repositories and install build tools
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install build-essential git

# Install xolominer dependencies
sudo apt-get install libssl-dev libgmp-dev libboost-chrono1.54-dev libboost-filesystem1.54-dev libboost-system1.54-dev libboost-program-options1.54-dev libboost-thread1.54-dev

# Get db4.8 source, compile and install
wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz
tar -xzvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC/build_unix
../dist/configure --enable-cxx
make
sudo make install

# Tell your system where to find db4.8
export BDB_INCLUDE_PATH="/usr/local/BerkeleyDB.4.8/include"
export BDB_LIB_PATH="/usr/local/BerkeleyDB.4.8/lib"
sudo ln -s /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so /usr/lib/libdb-4.8.so
sudo ln -s /usr/local/BerkeleyDB.4.8/lib/libdb_cxx-4.8.so /usr/lib/libdb_cxx-4.8.so

# Pull the xolominer source from github
cd
git clone https://github.com/thbaumbach/primecoin.git xolominer

# Go to source and compile the code
cd xolominer/src
make -f makefile.unix
# Start mining
./primeminer -pooluser=[xpm-payout-address] -poolip=[choose-your-server] -poolport=1337 -genproclimit=[threads-to-use] -poolpassword=[some-random-password-for-protection]


Answering to the subject of this question:

  Does moving funds from one account to another locally require a transaction fee?

Yes!

If you move(transfer) funds from one wallet to another wallet, there will be a transaction fee for sure.

But,

If you are doing this simply in your server, that is within the website and internal database, then no, there is no transaction fees.

A transaction fee will be levied only if you transfer from one wallet to another in blockchain, not internal to your own database.


From the poclbm source code, Switch.py line 219:

say_quiet('%s[%.03f MH/s (~%d MH/s)] [Rej: %d/%d (%.02f%%)]', (if_else(verbose, miner.id()+' ', '') , rate, round(estimated_rate), rejected_shares, total_shares, float(rejected_shares) * 100 / total_shares_estimator))

It's estimated_rate.

And how estimated_rate that found, you ask?
I tried looking at the source, but that didn't really clear things up.

self.estimated_rate = Decimal(new_accept) * (targetQ) / min(int(now - self.start_time), self.options.estimate) / 1000
self.estimated_rate = Decimal(self.estimated_rate) / 1000

I eventually found this discussion on bitcointalk. It states that the estimated rate is based on how many shares are submitted to the pool. I don't know what it's supposed to display if you're not using a pool.


It probably means your bitcoind has not enough memory to complete the request.


How do you publish a transaction which is cancelled if not claimed by a given time?

Using the blockchain you can't. If the transaction is in the blockchain with a reasonable number of confirmations it cannot be cancelled nor reversed. In that case only the owner of the recipient wallet can spend the balance. If for any reason the private key of that address is lost, the balance is irreversibly lost.

To reverse the transaction in the manner that you describe you would need to use some off-chain transaction method.


Bitcoin Wallet for Android supports backing up your private keys to external storage (e.g. SD Card). Just select "Export/Import private keys" from the action bar overflow menu.


Can I log-in to my wallet on new PC using just my wallet number and passphrase?

It depends what you mean, but the answer is probably "yes" either way.

Traditional wallets use a wallet.dat file, often encrypted with a password.  In this case, you would need the file and the password in order to use your wallet on a new computer.

Hierarchical deterministic wallets (HD wallets) use a single seed (possibly what you are calling the "wallet number") to regenerate all the addresses in a wallet, thus recreating the wallet.  Often times this seed is stored as word seed (possibly what you are calling the "passphrase"), meaning several randomly generated words that can be fed into an algorithm to regenerate the wallet seed, which in turn regenerates the whole wallet.  If this is what you mean, then you could restore your wallet with either just the seed, or the passphrase.  How to accomplish this from a UI will be determined by the particular wallet you are using.


CHECKSEQUENCEVERIFY After x time of last transaction

Whereas it seems, that this is not directly possible, cause bitcoin script does not allow to reference a transaction "within last 30 days", one could think about a "workaround" with a business logic watching the P2SH address. An approach could be the nested "if", which is allowed in bitcoin script. If ever within last 30 days there was a payment, the 30 days need to get "reset" - maybe you would need to play with two P2SH addresses, and shift the funds to a second addresses (and vice versa). If your business logic discovers a transaction in the last 30 days, the funds are transferred to a second address, and then again to the first address. For this second address you'd have the same set of rules, just the tx output script (for it's address) changes. The business logic could have a "known secret", that noone else knows, and then shift the funds between the addresses, just as an idea, like this:

IF
  OP_HASH160  <length 0x14> <SECRET> OP_EQUAL
  <business pubkey> CHECKSIG
ELSE
  IF
    2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
  ELSE
    30d CHECKSEQUENCEVERIFY DROP
    <Alice's pubkey> CHECKSIG
  ENDIF
ENDIF

Obviously it becomes clear, that there are fees involved in such a scenario. It depends on the frequency of transactions within last 30 days, and the value of the funds, that are shifted around. The fees should not eat up your funds... And then again, maybe one might look into using Lightning as "transport mechanism" to shift values around?


Is Bitcoin really anonymous?

No, most people describe it as pseudonymous.
When people say that, what they mean by Bitcoin is the tools, technology and network described by Satoshi Nakamoto in the original whitepaper where he described a system of electronic cash that did not rely on trusting third parties.
They usually don't mean the parasitic third-party businesses like Kraken that some people trust with their money.
Bitcoin itself can be relatively anonymous even when parasitic businesses choose not to be (or are forced by governments not to be).
If you feel these parasitic third-parties are exposing your identity more than you are comfortable with, don't use them.
Since the beginning of time, security and convenience work against one another. If you value something - privacy say - you have to invest hard work and money in achieving that and you have to sacrifice some or all convenience.

Note that although I characterise third party exchanges as parasitic, this is mainly for rhetorical effect. They are parasitic but many of them do offer valuable services and provide the convenience that many of us seek. I don't think it right to use a more sympathetic adjective like symbiotic because I think the vision offered by Nakamoto was of a system of cash that could thrive without any dependency on trusted third parties.


What is the function of the payload_checksum field in the Bitcoin protocol

"Full protection" is a relative term.  TCP packets include only a simple checksum, effectively just the sum of all the 16-bit words in the packet.  See RFC 793 section 3.1.  This is a fairly weak integrity protection mechanism.  The Bitcoin designers may have felt the use of sha256 gave better protection.  It may also, as you say, have been intended to provide forward compatibility for running Bitcoin over UDP or other protocols.  It may even just have been paranoia.


I bought bitcoin from an ATM machine but the person I want to send it to didn't not see it

Both of the transactions are confirmed and can be viewed using a block explorer. Furthermore, both of them were spent by your friend 6 hours ago.

Transaction 1
Transaction 2

In other words, those transactions have been seen by them and spent.


How does the network verify previous transactions when transferring BTC between two users?

I felt the absolute necessity to verify that these 'n' transactions actually took place. How would I find the relevant block?

A transaction consumes inputs, and creates outputs (new 'unspent transaction outputs' or UTXOs). For the transaction to be valid, each input must be a valid UTXO that exists on the network. Full nodes keep a continually updated index of all valid UTXOs, that they can check against incoming transactions.

A transaction input will reference the transaction which created it, via the transaction ID and the output index. So a full node will just look up that entry in the UTXO index, ensuring it exists and is being used validly.

  Would I decrypt the block to read it?

Blocks are not encrypted, but you will have to parse through the relevant blocks to obtain the relevant transaction data.

  Is this ever done in actual practice and is it expensive and time consuming to do it?

Yes, this is done by each and every node, for each and every transaction / block. Checking a single transaction is not a computationally expensive procedure, but there is consideration for the sum of verifications a full node must compute in order to synchronize with the network. In order to maintain a robust and decentralized network (which is integral to the network's properties), it is important that the total resource requirements to run a node remain relatively low, to ensure that a sufficient number of nodes are able to stay online.


What does the Bitcoin Core wallet backup do?

It creates a copy of the wallet file.
Bitcoin Core doesn't support recovery from just a key or seed phrase (at least, not yet).


Why aggregating transactions into blocks?

The Problem is that the nodes in the peer to peer network need to synchronize after every block. That means every new block needs to be shared with every participant in the network. This takes some time.
If someone on the other side of the world creates a block it might take a few seconds until this block reaches you. Even if this block contains only 1 tx. That's because latency does not reduce, if you reduce the block size.
Therefore you would have to give the network at least a few seconds time to synchronize after every transaction. This would reduce the overall tx per second drastically compared to aggregating multiple tx in a block and producing a block every 10 minutes on average.


I started build my own blockchain based on mastering bitcoin book using git on win7 and i have a problem

I believe you have the same problem reported in the link bellow:

https://askubuntu.com/a/490839

Just try to install autoconf. The autoreconf come with it:

sudo apt-get install autoconf


Is there a way to get the memory pool in order of newest first?

I think you have two options:

1) Patch bitcoin-core and make getrawmempoolentry return the mempool transaction sorted after entry_date. There is boost multi index that would be capable to fast sort the mempool transaction (https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L303)

2) You can try to improve your PHP sort speed. IMHO Arsort is not the best choice.


Where can I access a NXT public testnet node?

Start up Nxt on your local system in Testnet mode and display peers (on the Settings Menu (gear graphic) in the header bar). The peers with a domain name are likely to be public nodes. Here are a few:

nxt.noip.me, raspnxt.hopto.org, node1.forgenxt.com

For example, put node1.forgenxt.com:6876 in your browser to open the Nxt Wallet.

Some of the non-domain name (IP address only) will work too.


There are many facts that can increase a node's banscore. A node's banscore is updated in the Misbehaving function from main.cpp. Some of the reasons that trigger such update are:

Sending invalid blocks.
Sending duplicate version messages.
Not sending first a version message (before other communication).
Sending addr messages with more than 1000 addresses.
Sending inv messages with more than 50000 elements.
Sending header messages with more than 2000 elements.
Sending too large bloom filters.
...

Regarding transactions, it seems that they also may increase the banscore:

  // Punish peer that gave us an invalid orphan tx


Was bitcoin the first to use SEED phrase for recovering account?

Was bitcoin the first to use a seed phrase design.

I've no idea whether Bitcoin was the first cryptocurrency for which there was a wallet that supported a system of seed-phrases.
Not all Bitcoin wallets support seed-phrases. Notably the reference implementation Bitcoin- Core does not yet support seed phrases.
BIP39 - Mnemonic code for generating deterministic keys was defined or published on 2013-09-10.
According to Electrum their seed-phrase system was introduced two years earlier?

When you create a bitcoin account by then, do you get a seed phrase

Not in general.
Nor do you create a bitcoin account in general.
The archetypal process is to download a wallet program such as Bitcoin core and the first time you run it, it will generate a private-key. Wallets that support seed-phrases will instead generate a seed-phrase when first run and generate a private key from that.

Was there a timeframe when 2 types of virtual coins existed at same time.

Probably. I suspect the number of cryptocurrencies went from one cryptocurrency to thousands of cryptocurrencies in a very short period of time.
See

Some notable cryptocurrencies
A list of cryptocurrencies

Note that questions about any cryptocurrency other than Bitcoin would be off-topic here.


Can someone please explain the meaning of "neutrino" within the lightning network?

Building on the great answer by Andrew:

  1) What is this "neutrino" refered above?

Where as BIP 37 generates a client side Bloom filter including the HD wallet addresses, BIP 157/158 "Neutrino" creates a server side [can be any Bitcoin full node] Golomb-Rice filter including all transactions in a valid Bitcoin block. You are no longer querying if a specific transaction is in a block, which might reveal which transactions you are interested in, but rather you query which transactions are in a block, and then you download the interesting blocks from another node. Every valid block has only one correct BIP 158 filter, and you can thus cross reference against several different nodes.

  2) When is it expected to fully work , on what is timeline dependent?

I don't know how fast the core process will integrate BIP 157/8 [probably in two weeks?!], but because this is not a consensus critical change, it can be implemented by individuals much earlier. For example, Wasabi Wallet is creating Golomb-Rice filters on the centralized Wasabi back-end server, the individual wallets are checking which block contains their interested transactions, then the wallet is downloading that block on the Bitcoin P2P network over tor, or from your own full node. This provides great privacy improvements, as neither the Wasabi back-end nor the P2P network know exactly which blocks [due to tor / your own node] or addresses [due to BIP 157/8] you are interested in.

Further, Lightning Labs has a testnet version of their app which is running Neutrino, their implementation of BIP 157/8.

  3) And to what extent/how would this "neutrino" change the "Game" as implied above? What effects would it have on the way lightning works?

As Andrew points out, running your own full node and verifying the entire block chain is the best practice for both security and privacy. With SPV proofs you inherently "trust the miners" that the chain with most accumulated PoW is valid. "Inverted" block filters protect wallet privacy and is a great improvement to address filters. I'd say that in all regards: Own full node >>> Golomb-Rice filters > Bloom filters.


Welcome to the Bitcoin world.

  My first question is: When and How my private/public key was generated?

Your public key is calculated by your private key.

Where your private key is a randomly chosen number, so let's suppose that now we choose k value as your private key, from this we can apply a unidirectional cryptographic function, ie from the private key I can ALWAYS get my public key but it is impossible to contrary (unless expensive brute force attacks, where the game is not worth the candle)
This hash function is an elliptic curve function, I leave you the reference to a bitcoin book.

So I have my private key K where I apply my asymmetric encryption algorithm and get the public key.

P = hash_fun (K);

  My second question is: I know this is not a good practice but if i only know my private/public key in clear format (not encrypted): Is there a way for me to "import" this public/private key into my bitcoin wallet. In other words, can i say if i know my public/private key, i know everything.

Yes, the wallet is formed by the pair (private key, public key) many wallets keep the whole pair but it is possible to get the public key whenever you want, if you know the private key, but not vice versa.

So your private K key is your wallet, or rather what makes your wallet alive


why should I backup zcash wallet regularly

The BIP32 specification allows a user to derive many keys from a master extended private key, and this master key is derived from a seed (often, a mnemonic phrase). This allows the user to just back up one piece of data (the seed phrase), knowing that they'll be able to use it to derive all subsequent keys in their wallet.

Prior to the implementation of BIP 32, most wallets were a collection of keypairs that were independently generated at random, so one key would bear no relation to the next. In this style of wallet, every time you generate a new address, you need to save a new backup copy that includes the new address. Older backups would not contain the info that allows you to derive the same new address.

I am not extremely familiar with Zcash, but I would guess that not all implementations of their wallet software use a BIP32 style wallet architecture, thus the recommendation for regular backups (similarly, not all bitcoin wallets use BIP32).


There is no mathematical way to determine the value of Bitcoins (or shares of real companies, currencies and similar). It's value is how much people that use it value it. The best indicator what the price is is its exchange rate on various exchanges on the internet like BTC-e, mtGox, Bitstamp and many more. Bitcoins can more or less be related to more traditional currencies when it comes to theoretical background, valuing and more, but take in account Bitcoins are not backed nor managed by anyone or anything. It's all virtual. To look at the price and maybe analyse it you can hop over to bitcoincharts and take a look.


The inflation voting and the federated voting in the SCP consensus algorithm are happening at totally different levels of abstraction.  Inflation voting is a property of your wallet, stored in the ledger.  Whatever you set it to stays in effect until you change it.  The inflation algorithm, when it is run, just goes off the inflation votes in the ledger.

Now a validator in SCP could try to prevent you from changing your inflation destination, which would be the same as trying to prevent you from sending a payment.  If that validator (or some validator it is colluding with) happens to be the highest priority node in the nomination protocol for one ledger, then it could indeed potentially censor that request for that ledger.  But as soon as an honest validator leads the nomination protocol, the previously censored transaction will make it through nomination into the balloting process.

Once the inflation adjusting transaction makes it through nomination, bad validators could refuse to participate in SCP balloting, which is akin to crashing.  Whether or not that crash brings the network to a halt depends on whether there are sufficient remaining good nodes to form a quorum.


What can I do if I suspect that my Mycelium word list backup has been compromised?

There is no way to cancel the backup. Also you cannot be sure if it is comprised until the person actually spends the funds.

Transfer the funds to a new wallet
Diversify risk: Don't but all funds in one wallet !


Does a blockchain need a distributed hash table?

No. Peer discovery does not use a distributed hash table and cannot use a DHT. Once you are connected to the network, there is no need for you to find more peers to connect to (and most nodes have a limit of 8 anyways as that is Core's outbound connection limit).

The broadcasting of transactions and blocks themselves does not rely on the broadcaster to find all peers and send the data to each peer. Rather it simply sends the transaction or block to the peers it is connected to, and then those peers check the block and transaction, and if it is valid, they will send the block or transaction to their peers, and so on and so forth.


How to install Berkeley DB 4.8 on Linux?

You can compile it using this script in the Bitcoin Core repository:
https://github.com/bitcoin/bitcoin/blob/master/contrib/install_db4.sh . It will give you instructions about how to then ./configure with this compiled version in order to build the project.
Instructions about building Bitcoin Core are available in the /doc folder, for Unix systems it is at
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md


So is there a nice tutorial which explains how to start mining using FPGA.

Not really, not a "starting from scratch" one.

  Or this is so complicated?

Yes, it is quite complicated - in order to work with FPGAs, some additional skills on top of software are required.  You need to understand logic design and some (fairly basic) electronics in order to make a successful FPGA.

However, as a learning project, if it's something that interests you, I'd say it's worth a go - you'll learn a lot, but it won't be a quick-and-easy learning experience :)

But start small - first off, write an FPGA which just flashes an LED on and off slowly - that enables you to learn lots of the low-level details without a complex logic design going on.  The FPGA equivalent of "Hello World"!

EDIT:

If you've already done some FPGA work, then "all" you need to do is build a SHA implementation, some method of getting data to and from it and a little control logic.  I haven't done it myself, but I got about that far along a "thought-design" before deciding I wasn't sufficiently interested to pursue it further.


BOP: Not authorized to receive from the temporary destination

Tamas has already found a workaround for this issue over on the Apollo JIRA

You need to change your apollo.xml to use the "default" virtual host id, instead of the one that is configured by the Apollo deployment.  Its possible that the client side (BOP) needs to be configured to specify the virtual host to use somewhere, but I have no idea where, so this works for now.

<virtual_host id="default">


Can I use Bitcoin elsewhere except in the deep web?

Yes. You can use bitcoins in many places. There are Bitcoin exchanges where you may exchange your coins for USD or vice-versa. You can also use them on various websites like Newegg for example.


Bittrex: What Error Do You Receive for Spamming the API?

It isn't clear from Bittrex what error message is received when you encounter a limit. They just say that the request will fail. According the latest information from Bittrex Accounts can query the API up to 60-times a minute, once per second.

That said, there is a "success" flag returned for every request to the Bittrex API. I would imagine that this would be "false" and there would be some sort of message explaining the error. Maybe just look for false?


Installing Electrum on a cold wallet linux usb

For now you can use AppImage file from electrum.org website. Download AppImage to your Ubuntu USB, then:

$ chmod +x electrum-3.3.8-x86_64.AppImage
$ ./electrum-3.3.8-x86_64.AppImage


Why was it chosen to adjust difficulty every 2 weeks (rather than 2 days or every few blocks)?

Yes, there is a risk with adjusting the difficulty every block. It entirely depends on the method of adjusting. With how Bitcoin does it, if you adjusted every block, the difficulty would vary wildly due to the variance in times between blocks. However other algorithms for determining the difficulty may be able to account for that.

Adjusting every 2 weeks allows for the average time between blocks to be close to the actual time between blocks (by the law of large numbers) so that the adjustment can happen without being effected by the variance in times between blocks. The method used by Satoshi is very simple and straightforward with its effects easy to see and model.

Like almost every other "magic number" used in Bitcoin, the 2 week interval appears to simply be an arbitrary number with no real reasoning behind it.


why is the number of confirmations rising yet i haven't been credited with the bitcoins?

TL;DR: when you interact with a custodial service (ie you don't own the privkeys), it is entirely up to that service to 'credit your account' appropriately.

There are many types of Bitcoin wallets, but on a fundamental level we can draw a line between two types of wallets: those that give you access to your private keys (non-custodial), and those that do not give you access to your private keys (custodial).

If you send funds to a non-custodial wallet, you will retain the ability to do whatever you please with those funds, because you own the private keys (which are what allow the software to create valid transactions). Even if the wallet software you use ends up being broken, you can always just import the keys to some different wallet to recover your funds (assuming the wallets being used follow the industry standards of BIP 32/39/44/84 etc).

If you send funds to a non-custodial wallet, there will generally be a waiting period between the transaction confirming on-chain, and the service you sent funds to 'crediting your account'. The length of this waiting period is entirely up to to the service, but generally it will be several confirmations on-chain (meaning, you have to wait for a few blocks after the one your transaction confirmed in). This waiting period is a safety mechanism for the service: it helps ensure they are protected in the case of a chain re-org that could potentially erase recent deposit transactions from their customers.

So with all that in mind, if you are waiting for your custodial account to be credited, the most you can do is contact the service in question to see what the status of your account is. Since they own the private keys for the address you deposited to, they are the only ones that can now spend the coins you sent to them.

Remember: you must fully trust a custodial service to credit your account properly. When you choose to interact with any custodial service, it is prudent to consider what recourse you will have in the case they do not properly credit your account. Are they a legitimate business located in a jurisdiction that will hold them accountable to theft or other abuses? Or are they a service run by anonymous individuals, against whom you will have no possibility of recourse?


From this week's Bitcoin Optech

  One well-known method for soft forking an increase in the Bitcoin
  block size is extension blocks—a data structure that’s invisible to
  nodes that haven’t upgraded to the soft fork and so is not subject to
  their historic limits on block size. By itself, this is an undesirable
  method for increasing block size because preventing old nodes from
  seeing the transactions in the extension block also prevents them from
  being able to enforce any other consensus rules on those
  transactions—such as rules that prevent a malicious user from spending
  other users’ bitcoins or from creating more bitcoins than allowed by
  the 21 million bitcoin subsidy schedule.

  However, one doesn’t need to increase block size to increase the
  amount of data that can be added to the block chain per minute—it’s
  also possible to increase capacity by increasing the frequency of
  blocks (reducing the average time between blocks). A method for gaming
  Bitcoin’s difficulty adjustment algorithm—called a time-warp attack—is
  well-known among experts and has been used successfully in
  demonstration attacks against Bitcoin’s testnet and real attacks
  against altcoins. (Note: although Bitcoin is technically vulnerable to
  this attack, it’d be a slow attack that would give the userbase a
  significant amount of time to respond.) By itself, increasing block
  frequency is also an undesirable method for increasing capacity
  because shorter block intervals increase the effectiveness of miners
  with large amounts of hashrate and so is likely to increase mining
  centralization.1

  Perhaps disproving the saying that “two wrongs don’t make a right,”
  this talk describes a novel way of combining extension blocks and the
  time-warp attack to allow both upgraded nodes and old nodes to gain
  the same capacity increase and see all the same transactions for
  validation while simultaneously slightly reducing mining
  centralization risk. Upgraded nodes would validate one or more
  extension blocks (called “forward blocks”) that provide additional
  block space with a centralization-reducing 15 minute average interval,
  but the upgraded nodes would also restrict the time stamps in legacy
  blocks to ensure a permanent (but limited) time warp attack increased
  the frequency of legacy blocks enough to allow them to include the
  same transactions that previously appeared in the forward blocks.

Video / Transcript / Paper


Is this the proper way to use Bouncy Castle to generate a Bitcoin compatible key?

Below extract should answer your question.

public class ECKeyPair implements Key
{
    private static final SecureRandom secureRandom = new SecureRandom ();
    private static final X9ECParameters curve = SECNamedCurves.getByName ("secp256k1");
    private static final ECDomainParameters domain = new ECDomainParameters (curve.getCurve (), curve.getG (), curve.getN (), curve.getH ());

    private BigInteger priv;
    private byte[] pub;
    private boolean compressed;

    public static ECKeyPair createNew (boolean compressed)
    {
        ECKeyPairGenerator generator = new ECKeyPairGenerator ();
        ECKeyGenerationParameters keygenParams = new ECKeyGenerationParameters (domain, secureRandom);
        generator.init (keygenParams);
        AsymmetricCipherKeyPair keypair = generator.generateKeyPair ();
        ECPrivateKeyParameters privParams = (ECPrivateKeyParameters) keypair.getPrivate ();
        ECPublicKeyParameters pubParams = (ECPublicKeyParameters) keypair.getPublic ();
        ECKeyPair k = new ECKeyPair ();
        k.priv = privParams.getD ();
        k.compressed = compressed;
        if ( compressed )
        {
            ECPoint q = pubParams.getQ ();
            k.pub = new ECPoint.Fp (domain.getCurve (), q.getX (), q.getY (), true).getEncoded ();
        }
        else
        {
            k.pub = pubParams.getQ ().getEncoded ();
        }
        return k;
    }

}

Check out https://github.com/bitsofproof/supernode for more details.


According to another question about an Electrum error message the error message is just passed along by Electrum and originally was generated in BitcoinQt:

According to rpcprotocol.h in the source code error -26 has the following meaning:

 RPC_VERIFY_REJECTED = -26, //! Transaction or block was rejected by network rules

Guessing from the word "dust" appearing in the message, was the amount you were trying to send below 5430 satoshi? That would be considered dust, and perhaps electrum would not send a transaction with dust.


How can I reproduce them if I decide to create the charts myself?

$ bitcoin-cli gettxoutsetinfo
{
  "height": 614643,
  "bestblock": "0000000000000000000323e3aff59d74ab52e74f4dc5cfb9696ddb69e9857d9c",
  "transactions": 38728071,
  "txouts": 65228219,
  "bogosize": 4902482106,
  "hash_serialized_2": "a153439cccb341a5ac149562c90bca499e3a809ccf2075e2de17bc2b9d83d0ee",
  "disk_size": 3922698456,
  "total_amount": 18182867.32125828
}

65M is most correct. It's unclear where the value of 106 Million could possibly be coming from.

  The following website I think adds utxo from the gensis block

It doesn't really matter, there's 3 outputs which are "created" but are invalid, one in the genesis block and two in duplicated coinbase transactions. In the scale of the chain this is almost entirely lost to display precision anyway,


Broadcasting a transaction as a 3rd party

If you have send your transaction but it does not appear on the blockchain yet it mean it is still in the mempool, the place where transaction are waiting to be taken by a miner.
Miner incentive are to take the transaction with the biggest fees first, so yes you can "double send" your transaction using the same element but with an increased fee, so that it has more chance to be mined fast.
You can check this question for more detail:
When increase transaction fee three times in few minutes - transaction had an attempted double-spent?


What happens if full nodes don't check for double spends or deliberately lets a double spend TX pass and then this full node relays the transaction?

Since the miners trust these nodes to verify transactions, ... since miners don't check for double spends.

What makes you think this? Miners are also nodes; they are a subset of nodes. Miners still receive and verify all transactions, they don't just blindly trust what some other node has given them. Miners are incentivized to check transactions as including any invalid transactions means that the block will also be invalid and thus be rejected by the other nodes and miners on the network.

If a miner produces an invalid transaction (e.g. by including a double spend), the block will be considered invalid. Miners do not determine what is valid and invalid, nodes do. So when the nodes on the network receive that invalid block, they will reject it as invalid and not add it to their blockchain. Furthermore, since miners are also nodes, other miners will reject the block and thus they will not mine on top of it.

If miners mine on top of the invalid block, there will be a blockchain fork. The nodes on the network will refuse to follow a chain that contains an invalid block, even if it has more work. They only follow the valid chain with the most work, and an invalid block makes that chain invalid.


How is the Bitcoin node network different from the IOTA network?

As a bitcoin user, it is beneficial to run a full node because that allows you to independently validate the current state of the network yourself, without having to trust the actions or information of a third party. The user receives no monetary reward, but the ability to trustlessly interact with the bitcoin network is a very important feature, that is very core to any decentralized cryptocurrency network.

As an Iota user, you cannot attain the same level of trustless interaction. As I understand it, Iota employs a ‘coordinator node’ that basically has admin rights to the network, so you must trust that the coordinator will not act maliciously, or be otherwise compromised. You can run a node to check transactions yourself, but if the coordinator decides to freeze your coins, having a node will not help you.

So I wouldn’t agree with the comparison, or at least I would argue it is not a good line of reasoning. The level of trustless interaction that is enabled by running a bitcoin node is simply not possible to achieve in Iota due to the existence of the centralized coordinator position.


Why doesn't Multisig provide better security for hot wallets?

Multisig scriptpubkeys do increase the overall size of the transaction.  This is because when redeeming the output sent to the multisig script, a number (typically larger than one) of signatures have to be provided for validation in the redeeming transaction.

As for security in multisig, it depends on the setup of keys, and the scriptpubkey that ends up being executed.  For example, for a 2-of-2 multisig script (where two signers must cooperate), it might seem that this script is "more secure" against an attacker obtaining one of the keys, but if both keys are kept on the same device, then there is no security to be gained from a multisig.
On the other hand, if the script is a 1-of-2 multisig, then even if one of the keys is highly secured but the second is not, then the security in having a second signer (secured) is subverted.

Bitcoin's scriptpubkeys can be programmed to require not just multiple signers, but also conditions on when these multiple signers should participate or when they shouldn't.  We could set up a 2-of-3 (requires at least 2 of the 3 predetermined signers to participate) multisig scriptpubkey such that :

The first key is a "low" security key controlled by the user
The second key is a "moderate" security controlled by a 3rd party
The 3rd key is a "high" security key, known only to the user but is normally in cold storage and not used

In normal operation, the low security and medium security signers will cooperate to sign the user's transactions.  The user can rest easy knowing that even if their low security key is obtained by an attacker, the funds will remain safe.  The attacker will need to obtain the medium security key (the one that belongs to the 3rd party service) as well to actually move the funds.
If the service itself disappears, the user can still make use of their high security, cold storage key to complete the script with two signers, so they are never "locked out" of their funds.

There are even more ways to upgrade this setup, using ntimelocked transactions, or encoding a lock time in the script itself using op_csv or op_cltv.
I believe Greenaddress is using a setup very close to this.

So to answer your question, multisig is just a tool.  The security (or not) gained by using this tool depends on the way that it is used.


Trying to see, how this tx was successfully confirmed (in 2013) in the blockchain should reveal the secret of this script. The previous comments give already an idea, what the script is doing, but doesn't explain all. So I try to decompose further.
Assumption is, that sigscript of the spending tx goes to stack, then followed on top by the pubkey script. To verify the signature, the previous funding tx would need to be converted to an unsigned tx, so I remove the sig from orig tx, replace it with pubkey script, and change input script length:

 01000000 01 A214A2DAF91691AFDD491FD00D894EB3301E35BC18B5554B14E12843037E954C (<-- reverse hex !)
  00000000
  23         (<-- length is decimal 35 Bytes, reversed, hex 0x23)
  2102085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33AC7C2103F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4AC7C5379A820D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C875379A820F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226879A5479827701200122A59A5379827701200122A59A6353798277537982778779679A68 (<-- placed pkscript here into sigscript section)
  00000000   (<-- interestingly, Sequence is not FFFFFFFF)
 01 C06C3C0000000000 23 21039DC85F5FE062D4EEF0470FA96D4BBCFFF0096C62042333CD05AD491536560443AC DA538652

which is serialized and double sha256 hashed:

01000000014c957e034328e1144b55b518bc351e30b34e890dd01f49ddaf9116f9daa214a200000000B52102085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33AC7C2103F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4AC7C5379A820D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C875379A820F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226879A5479827701200122A59A5379827701200122A59A6353798277537982778779679A680000000001c06c3c00000000002321039dc85f5fe062d4eef0470fa96d4bbcfff0096c62042333cd05ad491536560443acda53865201000000

4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3

This double sha256 hash, pubkeys and sig (from the spending tx) matches with these pubkeys:

  ssig1:
  30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
  pubkey in HEX:
  03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
  pubkey in PEM:
  MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=
  double sha256:
  4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3

  ssig2:
  3044022045d08719828fbd93e49c9223e63f4d2dab2de6c568e1faa2cccb33adf2575d2c02200c00126cb0105275040a963d91e45460147e40451b590485cf438606d3c784cf
  pubkey in HEX:
  02085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33
  pubkey in PEM:
  MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgACCFxmAGV1ZqzC1jgqR7w/MkAI0qoQlA3XcFpIqipaXjM=
  double sha256:
  4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3

Quick verification with openssl (hence the pubkey in PEM format):

sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
hash=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex
echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem
printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex
openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex

OK, the part for the signature is clear. So looking further at the pkscript, I'll try to decode:

pubkey1  21 02085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33 AC 7C
pubkey2  21 03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4 AC 7C
         53 79 A8
hash1    20 D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C
         87 53 79 A8
hash2    20 F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226
         87 9A 54 79 82 77
         01 20
         01 22
         A5 9A 53 79 82 77
         01 20
         01 22
         A5 9A 63 53 79 82 77 53 79 82 77 87 79 67 9A 68

The problem I see is, that your statement somehow doesn't seem to match:

if (sha256(dat1) == hash1 &&
    sha256(dat2) == hash2 &&
    size(dat1) == 32 or 33 &&
    size(dat2) == 32 or 33) {
    if (size(dat1) == size(dat2)) {
       return checksig(sig2, pk2);
    } else {
       return checksig(sig1, pk1);
    }

The stack would look after sigscript:

[ssig2]
[ssig1]
[0x00]
[0x00]

And on top the pkscript would follow:

21: OP_DATA_0x21:        length compressed Public Key (X9.63 form, 33 Bytes)
    02085C6600657566:ACC2D6382A47BC3F:324008D2AA10940D:D7705A48AA2A5A5E:33
    corresponding bitcoin address is:   152q849uVmoB5oRcZ4d4tJHyRuB6FPB9Hz
AC: OP_CHECKSIG:         sig must be a valid sig for hash and pubkey

--  this would check the pubkey1 against ssig2, remove pubkey and [ssig2] from stack, and leave [TRUE] on stack

7C: OP_SWAP:             top two items on stack are swapped

--  this would swap [ssig1][TRUE], so [ssig1] is on top of stack

21: OP_DATA_0x21:        length compressed Public Key (X9.63 form, 33 Bytes)
    03F5D0FB955F95DD:6BE6115CE85661DB:412EC6A08ABCBFCE:7DA0BA8297C6CC0E:C4
    corresponding bitcoin address is:   1BaJ2fYiAVnZC73MtX1LsyJBtXNZWDSkt6
AC: OP_CHECKSIG:         sig must be a valid sig for hash and pubkey

--  this would check the pubkey2 against ssig1, remove pubkey and [ssig1] from stack,
    and leave [TRUE] on stack
    [0x00][0x00][TRUE][TRUE]

7C: OP_SWAP:             top two items on stack are swapped

--  this would swap [TRUE][TRUE], reason is unclear

53: OP_3:                the number 3 is pushed onto stack

--  top stack element is "3"
    [0x00][0x00][TRUE][TRUE][0x53]

79: OP_PICK:             item n back in stack is copied to top

--  this would pop 1 element from stack, and bring [0x00] to the top of stack:
    [0x00][0x00][TRUE][TRUE][0x00]

A8: OP_SHA256:           input is hashed using SHA-256
20: OP_Data:             next 32 bytes is data to be pushed on stack
    D68DF9E32A147CFF:A36193C6F7C43A1C:8C69CDA530E1C6DB:354BFABDCFEFAF3C
87: OP_Equal:            Returns 1 if inputs are equal, 0 otherwise

--  hashed the [0x00] value, put OP_DATA on top, and compare it. OP_EQUAL pops two
    elements from stack. This would give [FALSE] on the stack. Stack status:
    [0x00][0x00][TRUE][TRUE][FALSE]

53: OP_3:                the number 3 is pushed onto stack
79: OP_PICK:             item n back in stack is copied to top

--  this would pick the [TRUE] value ??

A8: OP_SHA256:           input is hashed using SHA-256
20: OP_Data:             next 32 bytes is data to be pushed on stack
    F531F3041D313670:1EA09067C53E7159:C8F9B2746A56C3D8:2966C54BBC553226
87: OP_Equal:            Returns 1 if inputs are equal, 0 otherwise

--  hashed the [0x00] value, put OP_DATA on top, and compare it. OP_EQUAL pops two elements from stack. This would give [FALSE] on the stack. Stack status: [0x00][0x00][TRUE][TRUE][FALSE][FALSE]

-- interestingly, this hash would match to sha256(hash) provided in the funding tx, as mentioned in the previous comment. I stop further evaluation of the script here. My understanding is, that we have seen the spending script with two hex 0x00 values, followed by sigs. This does not match the pseudo code? Maybe more like this:

if (sig1 == TRUE &&
    sig2 == TRUE &&
    sha256(dat1) == hash1 &&
    sha256(dat2) == hash2 &&
    size(dat1) == 32 or 33 &&
    size(dat2) == 32 or 33)
    ...

However: I have somewhere an "off by one" at the second hash value (F531F3041D313670...). It should be OP_4 or OP_5 (instead of OP_3) to reach to one of the provided hash images. With the value 3 the OP_PICK would copy [TRUE] (from the sig verification) on top, instead the hash image at position 4 or 5...

I didn't follow the next opcodes, there are more conditions. Also sequence number is "00000000" (not "FFFFFFFF"), and LockTime is "DA538652" (decimal ), which is bigger than 500'000'000, meaning a unix timestamp. This translates to a date: Fr 15 Nov 2013 18:03:22 CET. The tx appeared in the blockchain on 2013-11-15 17:13:23.

So in summary I think, this tx was structured in a way, that someone gave out a keyword with the tx to a second party, and you needed to be able to sign and "know" the keyword. A type of multisig, yes. And, it could not be spent before a certain point in time (the tx would be kept in mempool, but we cannot see this anymore). Else only the owner would be able to spend the tx...

There is probably more to it, I leave it to the experts to decode the remaining part :-)


When will the Bitcoin Cash difficulty adjust next?

The original bitcoin adjusted difficulty every 2016 blocks, which would nominally be 14 days @ 6 blocks per hour.  The 238th such adjustment is due at block 479,808, and we are presently (early 4 Aug 2017) at 478,620 or 1188 blocks away on BCC.  I assume the original adjustment interval has not been changed.  35 blocks were generated in the last 24 hours, so at that rate it will take 34 days to adjust (~5 weeks).  However, miners can jump in and out of BCC according to price/difficulty ratio relative to BTC, since they use the same mining hardware and just different software.  So I expect the mining hash rate to be variable.

Note that BCC allows for larger blocks, and several have been mined that are >1 MB.  So even at 1/4 the block rate, theoretical capacity is twice that of BTC.  BCC transaction rate is running about 1/8 of BTC, so blocks are currently nowhere near full.  Since many exchanges and wallets are not yet set up to handle the forked coin, volume is likely to grow over the next month or two.


Why Ethereum is growing in USD but decreasing in BTC?

It means that the value of btc is increasing at a higher rate than the value of eth.  Therefore it takes less btc to buy eth, and the cost of eth in btc is dropping.


Regardless of what accounts they are in in your wallet, consolidating/spending your dust may require substantial transaction fees - maybe even exceeding the value of the dust. The major factor that comes into play is the size added to a transaction by each additional input. You can read a lot of info on the Bitcoin wiki about transaction fees.

Here are some strategies for reducing/eliminating the fees:

Include some dust in a free transaction. How much you'll be able to include without lowering your priority below the minimum for a free transaction depends on the coin-age you're spending in the transaction (large, old balance = high priority).
Include some dust in a paid transaction. The 0.0001 BTC per thousand bytes means that if you have a transaction that's only, say, 250 bytes you can add up to 750 bytes of extra data (in this case, dust inputs) for no additional cost.
Transmit your transactions directly to a free transaction relay/low-fee pool. For example, Eligius only requires 0.1 TBC (0.00004096 BTC) per 512 bytes.
Wait it out. If the value of a bitcoin rises substantially, the transaction fee limits will likely be lowered to account for that, so your dust will not be so dusty-looking.

If these all sound like a bit of a pain, that's because Bitcoin isn't really designed for micro-transactions, and much is in place to discourage spamming in the form of "dust".


Is brute forcing a private key with unspent coins getting easier?

It's increasing from approximately zero to approximately zero.
Since the starting seed of HD wallets is essentially random, I don't think this helps.
This isn't significant.


The redeem script for a P2SH-P2WPKH address is relatively simple. You take the RIPEMD160 hash of the SHA256 hash of the public key (same as P2PKH), this is known as the keyhash. The public key must be in compressed form. Then the P2SH redeem script is just OP_0 followed by a push of the keyhash. The keyhash is 20 bytes so the redeem script will always be 22 bytes long: 0014{keyhash}.


Are there any other anonymous developers like Satoshi Nakamoto and BCNext that abandoned their project?

There is also the CryptoNote creator Nicolas van Saberhagen.

From: https://en.wikipedia.org/wiki/CryptoNote#Controversy_and_criticism:

  The author of the white paper went by the name Nicolas van Saberhagen,
  although like Satoshi Nakamoto (the author of the bitcoin white paper)
  that name is likely a pseudonym. Saberhagen's true identity and
  location remains unknown. Some have claimed that the real creator is
  someone in the bitcoin community.

It gets interesting, because the community found the first CryptoNote (Bytecoin BCN) currency to be a likely scam.
The controversy is regarding the creator himself likely pre-mining the coin in secret before the "official" launch, as well as suspected of having an unfair mining advantage because of publishing a handicapped miner (later fixed by the community).
To give weight to the controversy, seems like the timestamps of the original whitepaper were fabricated as well.

For a longer read, the details have been presented here: https://bitcointalk.org/index.php?topic=740112.0

  tl;dr - CryptoNote developers faked dates in whitepapers. Bytecoin
  faked dates in fake blockchain to facilitate an 82% premine, and
  CryptoNote backed them up.


Can I send it to the wrong address format?

Addresses have checksums in them to prevent mistakes like these. Typographical errors can be detected because of these checksums. So a well designed wallet will not allow this, but nothing prevents a badly designed program from erroneously accepting an incorrect address format and decoding it into some invalid/impossible output script.

  The address format is correct, but is it possible to send bitcoin if sent to the ownerless address?

Addresses don't have owners. They have keys or other requirements associated with them. If coins are sent to an address for which the key is not known, or to an address with unknown redeem script requirements or impossible redeemscript requirements, then the coins are permanently lost.

  If 'A' happens to generate question2 address and use its wallet address, can 'A' use its coin?

If you miraculously manage to generate the private key of an address that has bitcoins sent to it then, yes, you can spend those coins. However, the likelihood of that happening is infinitesimal.


Since transaction fees are based on the "size" in bytes of the transaction, why is it cheaper use "sendmany" rather than just making several?

The actual purpose of a regular transaction is to create one or more recipient outputs to pay someone. One could therefore think of the recipient outputs as the "payload" of a transaction, and the remainder of the transaction as the overhead to achieve the transaction's purpose.
Let's assume that we send a single payment in a transaction with one input, the recipient output, and a change output. Assuming that the transaction only uses P2WPKH outputs, the input weighs 68 vB, each output ways 31 vB. The transaction also has a header of 10.5 vB.
This means that the total weight of the transaction is 10.5 + 68 + 31 + 31 = 140.5 vB, i.e. 140.5 vB per payment. Note that your wallet will also need to spend every change output it creates in the future, so we also incur a future "blockspace debt" of 68 vB.

Let's say our wallet performs a high volume of payments, and we have a bit of flexibility when we pay exactly, so we are able to batch multiple payments into one transaction. Instead of making one payment, we perform three payments in a single transaction. Let's assume that our wallet needs to use three inputs to fund the payment: 10.5 + 3 × 68 + 3 × 31 + 31 = 338.5 vB. Even though we still have the same number of inputs per payment, we now only need 112.8 vB per payment instead of 140.5 vB. And we only have to spend a single change output in the future instead of three, which saves us another 2×68 vbytes of future transaction weight.

More often than not, we might have a particularly valuable UTXO in our wallet, and we can fund all three payments with a single input. The calculation now becomes: 10.5 + 68 + 3 × 31 + 31 = 202.5 vB which drops us to 67.5 vB per payment, and still only a single change output.

Note that payment batching has diminishing returns with more payments as the cost per payment approaches the actual size of the output. E.g. for ten payments the weight drops to 41.95 vB per payment, for twenty payments it's 36.475 vB per payment, for 100 payments, it's 32.1 vB. Also, eventually, a single input may not be sufficient to fund your transaction.


If addresses are hashes of public keys, how are signatures verified?

The transaction's INPUT has ScriptSig which is both the signature as well as the public key.

http://en.bitcoin.it/wiki/Transaction#Data


POW based blockchains systems Majority Attack

The attack you are describing is correct. This is an attack against the "Common Prefix" property of the blockchain, which roughly states that it should be hard for an adversary to cause two honest parties to adopt two different blockchains at the same time when they have diverged for more than k blocks, where k is a parameter. In your case, you have set k = 6.

In fact, the attack you are describing has been analyzed in Satoshi's original paper. If you look at the last section (11. Calculations), Satoshi calculates the probability of success of the attack you described. Specifically, he examines the probability of adversarial success for various values of the variable he calls q, which indicates the adversarial mining power. For your case, q = 0.3. Then he uses the variable z to indicate the number of blocks one waits prior to accepting a transaction as confirmed, in your case z = 6. In Satoshi's analysis, this follows a Poisson distribution and roughly the probability of adversarial success is indeed p ~= 0.15. In fact, Satoshi precisely calculates the case z = 5 and q = 0.3 and gets p = 0.1773.

In the original paper, there are certain z recommendations for how many blocks one should wait for to achieve an adversarial probability bound of p < 0.1%. For q = 0.3, the minimum z that achieves this is z = 24. So, if you want to be able to withstand a 30% adversary, you must wait for 24 confirmations.

Satoshi's analysis is a bit rough, because it only takes one particular attack into account. Subsequent analyses have allowed us to quantify these probabilities against arbitrary adversaries, even unknown. The primary reference here is the Backbone analysis. In this paper, the Common Prefix property is stated precisely and proven to hold against arbitrary adversaries.

The Backbone analysis is an improvement over Satoshi's for several reasons. I will mention a few:

The probability distributions are specified precisely (as Binomial and Bernoulli distributions) and not approximately (as Poisson distributions).
The adversary is arbitrary and does not necessarily follow a strategy that we have predicted or know about.
The security is proven and not simply intuitively conjectured.
The system is modeled and analyzed precisely using theoretical computer science tools down to interactive Turing machines.

To see the Common Prefix statement precisely, look at Definition 3 (Common Prefix) under section 3.2 (Desired properties of the protocol). The fact that bitcoin has this property is proven in Section 4.2 (Common-Prefix property) under Theorem 15 (Common Prefix). There, a precise formula is given for k, the number of blocks you need to wait to know that the chain cannot be reorg'ed back to that point: k = ηκf. The variables η, κ, f are made precise in Section 4 (Analysis) under Table 1 (The parameters in our analysis). It is difficult to give concrete numbers to these variables, as they depend on the network health and performance as well as mining difficulty. For bitcoin, we have that κ = 256 is the bit length of the (mining) hash function. I estimate round duration to be, optimistically, about 10 seconds (time it takes for a large portion, say 90%, of the network to learn of a newly mined block header) and so since a block is found on average every 10 minutes, we have that f is about 0.0003 for bitcoin. I do not know how to estimate η precisely.

The point is that the Common Prefix theorem is attained for k when "the execution is typical" (typicality is established in Theorem 10), which depends on the parameters ηκ. A prerequisite for typicality is that the sequences of consecutive rounds examined are at least ηκ in length. The assumption that this quantity is large is needed to apply the Chernoff bounds to the Binomial distribution: Typicality is attained with overwhelming probability in this number. If this number is small, the probability is no longer overwhelming, and the security of the system can fail.

Such analyses are typical in cryptographic systems, including digital signatures, encryption schemes, zero-knowledge proofs, and so on. The adversary is capable of succeeding with a probability which is bounded by a function with one free variable: That free variable is the security parameter (ηκ in backbone's case) and the function is negligible in that parameter, meaning that the probability drops off exponentially as the parameter increases. In Bitcoin's case, the probability of double spending drops exponentially as the blockchain size on top increases, but is not negligible for k = 6, especially when the adversary is powerful.

To address your more concrete point that this is economically feasible: You are right that you can transfer $2M in a single bitcoin transaction. However, I find it unlikely that the recipient for such a transaction would consider it safe after k = 6; a value close to k = 25 must be used. It is sensible to accept lower values of k for smaller amounts and require larger values of k for larger amounts. While the exact probability is difficult to calculate, still most exchanges and other automated services accepting cryptocurrency payments apply reasonable bounds and I expect that they increase them for amounts that are in the millions of dollars (typically this is done by requiring human approval of a transaction for extremely high-value transactions, which definitely gives plenty of time for proper proof-of-work on top). The economic cost of forking the chain to cause block abandonment is briefly analyzed in the paper On bitcoin as a public randomness source. Given that analysis, one can balance the cost of forking the blockchain against the potential gains one could earn by performing a successful double spend, multiplied by the adversarial probability of success calculated from Backbone. This can allow a party to precisely determine their desired value of k for various monetary parameters, given precise adversarial bounds such as q = 0.3.

I know this answer was a bit technical and did not give many concrete numbers, but I hope it shed some light into why the attack you're describing is indeed possible even though we still would call it "negligible". Since you asked for my credentials, I am a PhD student in Cryptography focusing on the foundations of blockchain protocols at the Computer Science department of the University of Athens. Aggelos Kiayias, who wrote the Backbone paper, is my advisor (I did not contribute to that paper). As he is my teacher, I am quite familiar with his work, especially because we're using the model developed in backbone for subsequent work. I am a research fellow at IOHK where we are building the foundations of a cryptocurrency we call Cardano and analyzing it from a mathematical point of view. Probabilities of adversarial success in attempts to perform blockchain forks as well as their analysis come up in my own work in which I'm trying to construct sidechains interfacing multiple blockchains. We often prove negligibility bounds in these settings.


Well, Litecoin's main aim is to make mining easier for the common man.

The problem with pure SHA-256 mining is that it is not very hard to design hardware that can perform mining at an astonishing speed. We can see this with the currently very much ongoing rise of the ASIC mining industry.

Since scrypt is more complex when it comes to hardware - scrypt not only requires many processor cycles, but also requires intensive memory use - it is harder to design hardware specifically for scrypt mining.

The result of this is that Litecoin mining will be profitable for the average joe for a longer period of time than Bitcoin mining did, when it would be adopted just as fast. Since it does not, the arrival of dedicated scrypt mining hardware will be even more deferred, to the benefit of the miners.

Besides this, I have to agree with you that the other differences between Litecoin and Bitcoin are only minor. Total currency is really not that important since both are very divisible. And faster confirmations are not required either, most Bitcoin transactions are considered valid upon first notice, since it is hard to perform a double-spend attack. (Note that you should better require a transaction to have a fee included when you want to consider it confirmed upon first notice.)
Also, after one confirmation, pretty much all transactions can be considered final.


Is it possible to send one satoshi to every bitcoin address?

Yes. There are currently about 10 million unique addresses in the block chain, so 0.1 BTC would be enough to send a satoshi to each address. The transaction data would be about 340 MB. The network's anti-spam protections would make this project either very expensive (due to transaction fees) or very time-consuming.


if your transaction has 3 confirmations this means that your transaction is in the blockchain. well. many platforms have a "minimum amount of confirmations", for example i often see 7 or 10 transactions as requirement for acceptance of this payment. this has justified technical reasons. you should wait some blocks and then your payment will probably also be accepted.


Scalability problem: is the end of Bitcoin near?

TL;DR:
No, the end is not near—we're just getting started. 20× is boring, let's figure out how to do 100,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.
While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.
For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.
Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.
By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a few times only delays the necessary work. However, after exploring other avenues, and squeezing the most out of a small base layer, we can always come back to talk about increasing the base layer capacity, eventually.


How to verify Bitcoin Core Release Signing Keys

This answer depends on that you are using Bitcoin Core 0.13.1 and you have downloaded bitcoin-0.13.1-win64.zip, this answer will also work with any other bitcoin version or download with only change signer public key, checksum file and bitcoin download name.

First you need to import public key of the signer, in this case the key with id: 0x90C8019E36C2E964, you do that by --recv-keys command line argument.

gpg2 --keyserver pgp.mit.edu --recv-keys 0x90C8019E36C2E964

Or you can manually download it from: http://pgp.mit.edu/pks/lookup?op=get&search=0x90C8019E36C2E964

Next you need to download the signature file from her: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc, and store it in same folder where bitcoin core download is stored. Then you need to check that the SHA256 checksum is valid.

sha256sum --check SHA256SUMS.asc

Don't care about FAILED open or read or No such file or directory messages, you are looking for something like this:

bitcoin-0.13.1-win64.zip: OK

If the checksum is valid, then you validate that the signature is good (checking that the checksums file is not tampered with). This is done by:

gpg2 --verify SHA256SUMS.asc

This should output something like this:

gpg: Signature made Thu 27 Oct 2016 08:21:11 PM CEST
gpg:                using RSA key 0x90C8019E36C2E964
gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>"

EDIT:
If you get following message:

gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964

You have problems with trust, in other words, the public key for Wladimir J. van der Laan is not marked as a trusted key in gpg. You can mark it with some easy steps.

gpg2 --edit-key 0x90C8019E36C2E964 ↵
trust ↵
5 ↵
quit ↵

You don't need to use 5 as trust, you can choose 1-5:

1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately


What happens if I receive a payment after deleting the payment request

You still own the address, so the payment would be received fine, you would just lose the additional notes you may have added to the payment request.


How can I check if my seed matches a BTC address?

In HD wallets it rarely happen that a gap of more than 20 is being used. It relates to bip32 standard in most cases. And it may happen in only few cases:
-if the receiver is a payment processor that puts out hundreds of invoices and only few are being paid.
It doesn't sound like your case though. I would suggest using IanColeman website, please remember to use it in offline mode and be very careful about it anyway. I wouldn't use it with a bigger amount of funds personally.


How to know that the account balance of a user needs to be updated after paying/sending an invoice?

Both lnd and and c-lightning will include the payment request when notifying you of a payment. I personally used it through lightning charge with c-lightning for satoshis.place.

For each invoice generated (aka an "order"), I would keep a record of it in my database, along with the pixels to be drawn. Then when I see a payment coming in I go and fetch the order and process it.

I'll describe a simple architecture, lets break it down in 2 steps: deposits and withdrawals.

Deposit

You're gonna need to maintain your own database of user accounts.
Include fields like: email, password, unique UUID and balance (you can add 2FA and API keys later).
Generate invoices for deposits, attach the UUID of the user that created it.
Increment the balance of the user when you see the payment come in, remember to do validation like checking amounts sent.

Withdrawals

Have users give you invoices, maintain a table of withdrawal requests.
There might be situations where there isn't enough lightning capacity to pay a user. In this case you might want to provide the option to do off-chain withdrawals instead.
Off-chain withdrawals can be batched with other withdrawal requests, depending on usage of your service. I.e. withdrawals go out at the end of the day / week. This would optimize block space usage and lower any potential related fees paid per user.

I think what you are asking for is essentially software to run your own payment processor. Think about Strike and OpenNode but open-source?

I'm really interested in this topic. I really like the idea of stretching the idea of "Swiss Bank" in everyone's pocket to "PayPal / Stripe in everyone's node". I have some code I've been working on bbut it's still closed source, was intending to release it once MVP. If you're interested we could talk more about this during the Lightning Residency!

-- Koala


looking for api for huobi.com for last price data


How much info share bitcoin nodes between other nodes?

The IP-addesses of Bitcoin nodes are not a secret. See addr
Nodes don't explicitly tell other nodes their Bitcoin addresses. Since nodes pass on details of other nodes transactions, working out which nodes originated a transaction isn't straightforward.
Since the set of Bitcoin nodes is constantly changing, and nodes go offline temporarily (or permanently), no node ever absolutely and definitely knows the IP-addresses of all nodes existing
Nodes don't communicate with all other nodes. Only with a few at any time.


Are there any revenue sharing blog websites that pay out in Bitcoin?

You can use https://anonymousads.com/ on a blog site. They pay in Bitcoin but don't host anything themselves as far as I know


How was Ethereum hard fork's replay attack was handled?

There's some history when it comes to ETH/ETC replay protection.

  How was this problem resolved for Ethereum?

Initially when ETH hard-forked to invalidate the DAO contract, both ETC/ETH networks did not implement replay protection for transactions. Instead, a split contract was written instead which relies on a split oracle built in Ethereum to identify if the contract was called on the hard-fork (i.e. ETH chain).

The contract logic is quite simple as you can see for yourself, it basically splits the original tokens and sends them into two different addresses depending on which chain the contract is called.

Nowadays, the ETH (hard-forked) chain has effectively implemented replay protection. So transactions executed on the ETC network will not be valid on the ETH network and vice-versa.

  Does Ethereum still have possibility of replay-attack if transaction is to be made from the very old wallet (the wallet which have no associated transaction after the fork)?

No.


Is there a central repository of bitcoin conferences?

It depends on what exactly you are looking for. If you want to publish academic research, the most well known conferences are:

Conference on Computer and Communications Security (CCS)
USENIX Security (USENIX Security)
IEEE Symposium on Security and Privacy (S&P)
Financial Cryptography and Data Security (FC)
Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT)
Network and Distributed System Security Symposium (NDSS)

Note that if you are not academically interested, those might not be for you.


I think the main thing you've missed is the problem GHOST set out to solve.
It's first and foremost intended as a scalability/speed upgrade. We want to increase the size of each block and/or decrease the interval between blocks. Either of these would increase the ratio between propagation time and block interval.
The higher the ratio is, the more we get that blocks are mined at the same time. And then lots of honest hashrate is wasted on blocks that get orphaned.
This makes it easier for an attacker to attack, because he doesn't need to have more hashrate than the honest network - he only needs to have more hashrate than the unwasted hashrate of the honest network.
This isn't much of a problem now, when blocks are 10 minutes apart and are about 3MB. But if we were to try to, say, reduce the interval between blocks to 1 second, the time to propagate blocks will be a multiple of the average time to find a block, leading to huge waste and an easy attack.
GHOST (and the more recent SPECTRE) is designed to allow us to increase block size or speed without this waste.
Contrary to what you said, simply adopting GHOST will not cause less branching in the block tree. It will just mean that we won't waste hashrate due to this branching.
Re question 3 - I think you've got things backwards. The way a double-spending attack works is:

Attacker pays merchant, tx is included in the honest chain.
Merchant gives product.
Attacker releases secret chain, where the tx is replaced by one that credits the attacker.
Attacker has both the product and his money.

If you are not up-to-date on the network state, and think the attacker's chain is winning even if it's not, you're actually better off - you will see that the attacker intends to not pay, and you will know not to send the product.
After I send the product, I want the whole chain to recognize the tx that pays me. Even if there are nodes which are not up to date, and briefly believe the attacker's chain is valid - that will resolve quickly after they receive the blocks they've been missing (and see that the honest chain has more weight).


Bitcoin now (as of a few hours ago) uses autotools to generate makefiles. You'll need to run ./autogen.sh first, then ./configure, then make.