Sent Bitcoin to my electrum wallet address without hitting request first now it says its confirmed and i have no money after requesting it

Can I still receive my coin

For privacy, many wallets use a new receiving address for each transaction but sending money to an old address should still work.
You can use one or more of the public blockchain explorers to find out the status of transactions involving the old address.

Addresses
To view a full list of addresses known to your wallet see I can't find my bitcoin address
If the address to which you sent the money is not on that list, it is possible you sent the money to someone else's address and have lost the money with no chance of recovery. If you have multiple wallets or deleted a wallet and reinstalled the same software or another, it is possible you sent the money to an address that no-one has control over (unless you were diligent in making and retaining backups of the wallet and records of the private-keys and/or recovery phrases)
If the address is on that list and shows a balance of zero, where blockchain explorers show a non-zero balance, it is likely there is a problem with synchronisation.

Synchronisation
See I didn't receive a Bitcoin Payment. What does it mean when the Client is synchronizing?
If your wallet is having problems synchronising, you won't see your money until it succeeds
An unofficial Electrum Beginner's Guide says:

You can monitor progress from the Network window. Access it by clicking on the circle to the lower right of the main window. When the block count under “Blockchain” equals the height indicated for the servers you’re connecting to, Electrum will be fully synchronized and all confirmed transactions should be displayed properly under the History tab.

If the servers that Electrum connects to are themselves not synchronising, your wallet might not know that it is not  synchronised with the main body  of the bitcoin blockchain network. -- check the blockchain height in your wallet in the network tab (blockchain: nnnnn blocks) - make sure it agrees with blockchain explorers --

Checking "balance" using another wallet
Download and install a new wallet (e.g. on another computer you own)
Watch-only
Import the address into the new wallet
Note that this doesn't mean the address is yours and gives you no ability to spend money at that address.
Full-Access
Export the Private key from Electrum

Wallet > Private Keys > Export.

Import the private key into the new wallet

Footnote, probably unrelated:
Electrum phishing & theft
According to https://electrum.org/#home currently

Warning: Electrum versions older than 3.3.3 are vulnerable to a phishing attack. Do not download Electrum from any another source than electrum.org.

There are fake versions of Electrum which steal your money.


How to avoid price pumps & dumps when trading with bot?

In a normal exchange, you have an order book of buys and sells. Usually, they don't cross over, that is, if the highest buy is 219, the lowest sell will be higher than that.

What you're doing is buying at market (aka market order) so any buys you do simply match the lowest sell and any sells you do simply match the highest buy. Whenever the two cross, they are simply filled by each other, so the gap will be there 99% of the time.

What you can do if you want to avoid this is to use limit orders. Generally, though, you have to wait for them to fill as you need price movement in order for that to happen.


The logic of exchange services of bitcoin

Transfer of a transaction is immedeate. You can send from one address to the next, and it appears within seconds. However: it is not confirmed (in a block). It takes in average 10 mins, that a new, valid block is created. The block is made of many transactions, that were validated before by the node. There is a mathematical puzzle to be solved, which is adjusted from time to time, so that the "block time" is always equivalent to 10min in average. You can send your tx anytime you want, it just might take some minutes, until it appears in a valid block.
I ercommend reading some more, maybe the online available book of Andreas ("Mastering Bitcoin"). It explains pretty well the details.


How to set up a node on Testnet of Lightning network on the world map

You need to start your lightning server with --externalip flag set to your public IP address. The specific command depends on which implementation you are using at the moment one of lnd, c-lightning or acinq.


guiminer shares 0 accepted 6 stale/invalid,what does the message mean?

Uh Oh, the high level answer is it means you are not getting any bitcoins.

The lower level answer is harder to figure out without more information, basically, somewhere in the software/hardware stack is a problem that is preventing you from returning valid shares.  It could be a hardware problem but most likely it is just a configuration problem.

In the comments below, can you answer:
1:  What hardware are you running this on?  CPU?  GPU? model?
2:  What does your GUIminer window look like (attach a screen shot).
3:  Did you create a worker on deepbit.com?

Welcome to StackExchange!


Try this, they have a very simple API:
https://blockexplorer.com/api-ref


How Can I Ensure Private Key is Valid on my Paper Wallet?

Checking the validity of a private key is a really compute-intensive task to do by yourself, but you can do this without actually using the private key to send coins (so no need to do it using pen and paper).

On the bitaddress.org website the Wallet Details tab lets you enter the private key and after clicking View details your bitcoin address should be showed in either Bitcoin Address Compressed or Bitcoin Address field.

But of course, you should not give away your private key, especially not online.

The site is actually an all-in-one HTML page, that is it can be downloaded as one file and it will work offline as it does every calculation in your browser window (no data you entered will be sent to the server). You can save to your computer (Ctrl-S in your browser) and open it in your browser without Internet connection.

I'd suggest to do the check at least in a private browsing window, or a live system (keep reading).

If you would like to do an independent check, use a Bitcoin Core client and create a new empty wallet (if you have it running, shut it down, move the wallet.dat somewhere else and start it again), go offline (disconnect your machine from the Internet, you will not need synchronization anyways) and try to import the key as it is described in this question. The client will check the private key, if that's invalid then an error will be reported (I changed a character, it reported Invalid private key encoding (code -5)). After this you can close the debug window and check your Bitcoin addresses in File >> Receiving addresses. After this, shut down your client and delete the wallet.dat. If you have moved the wallet.dat move it back now and keep using that.

Of course using this method writes your private key to the HDD/SSD of your machine, therefore even after deleting the wallet it is likely to be recovered using forensic/data recovery tools. If you'd like to avoid this you will need to use a disposable system, like a live OS that retains no data.

You can for example download Ubuntu and put it on a pendrive then boot from it, by default it will not save anything you do. You can also download the client from the Bitcoin Core download page (choose "Linux (tgz) 64 bit"), save it to the pendrive using your regular OS and then when you boot the Ubuntu you can simply extract it to the Desktop and run from there, all offline.

If you'd want to be even more careful then before booting the Ubuntu you should disconnect all other drives from your machine, leaving only the pendrive connected. Also, after using the Ubuntu and returning to your regular OS search for a method to securely wipe your pendrive and do that.

And another step would be a computer dedicated solely for this purpose, for example a Raspberry PI. Download a base image, put it on an SD card, copy the saved bitaddress webpage beside then connect a display, a mouse and a keyboard and power it on. The Bitcoin Core client has no official binary release for this platform but you can build it from source if you're adventurous enough.


You are very correct, but:

I would use getaccountaddress instead of getnewaddress. If the user doesn't exist, which is the case for a new user, the wallet will create a new one anyway.
I always would use the user's name to recover from the wallet his address, there's no sense to store it again on a DB. ¿?

The time for a balance to be confirmed depends on the coin and its network.

$bitcoin->move($useraddress, $myaddress, $amount) Yes, it is instantaneous. There's no transaction broadcasted to the net.

How can I test out my bitcoind/php application with testnet? Anyone has any experience of this? ---> Go to the wiki, U have to set a specific parameter on bicoin.conf


It is most likely (blockchain may figure this out differently) the priority of the transaction compared to others. Nodes add highest priority transaction and repeat until they reach the block size limit.

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

priority = sum(input_value_in_base_units * input_age)/size_in_bytes


What methods are available to accept Bitcoin payments?

There are a number of approaches, and the best method for you will vary on a number of factors.

For instance, if you sell a digital good it might be easier to simply sell the item through an online store like CoinDL, where you simply direct your customers there.

Similarly, if you sell a couple of items at a fixed rate, you could sell it on BitMit.net, again -- your e-commerce site simply directs your site visitors looking to pay with bitcoins there.  A blog post on Coinbase describes a "Buy Now" button modeled after another leading e-commerce payment solution.

If you already use an e-commerce shopping cart you might have an easy way to start accepting bitcoin if there is a module for that cart interface software that accepts bitcoin.

When following the DIY route, you can have the proceeds of your sales converted to fiat upon receipt.  Some exchanges (like Mt. Gox) offer "autosell" for shopping cart tools so that proceeds convert to USDs (or other currency) upon receipt.

The easiest way, however, is to use a payment processor like BitPay, WalletBit, Paysius, and ZipBit.  These are used in a similar way that a site uses PayPal to accept payment online.  The payment processor will provide all that is needed for your e-commerce site, and will provide a method to receive cash via a bank transfer.


What goes in the id/BTCUSD field for Mt. Gox "submit an order" API call?

This field is used to spcify the currency pair type of the return data, so leaving in BTCUSD works fine or changing it to a different accepted currency pair, such as BTCEUR, also works and just changes the currency denomination of the returned data.


How bitcoin distributed to more than 1 miner as bitcoin-mining lottery only choose 1 miner?

Your understanding of mining is correct. Using standard mining, you work on your own trying to hash a block trying random nonces until you find one that works.

When you find a block, you write in your bitcoin address into the coinbase transaction in the block and you receive the block reward (currently 12.5 BTC).

However, like you say because of the lottery principle, the probability that any single miner will find a block is tiny, so how do people make 0.00x BTC a day instead of making 12.5BTC every few decades? (when they find a block by chance).

This happens because of mining pools. A mining pool is a group of people that work together to mine, and when one of them finds a block they split the reward based on how much work each miner did. This means that you earn the same amount of BTC every time the pool mines a block, regardless of who in the pool mined it (giving you stable income).

When mining in a pool, you don't mine blocks directly, but you mine a subproblem created by the pool (esentially much easier blocks). This means that the pool can actually verify how much work you did by checking your solutions to the subproblems, instead of just trusting every miner to correctly report how much work they contributed.

This also means that a miner can't just take the block for themselves, as only the pool has the information to actually construct a block. Thus, many people can mine together without every miner needing to trust every other miner. They just need to trust the pool. The pool usually takes a 1% cut or similar of the mining reward.


Is it possible to have multiple accounts in MultiBit HD?

Only a single account ("Account 1" in myTrezor.com terminology) is supported in MultiBit HD.

This is due to limitations of how the transaction data is obtained from the Bitcoin Core nodes. It is explained in the help in this article in the section headed "Bloom filtering and single HD account support":

https://multibit.org/en/help/hd0.1/how-spv-works.html

Source: I am one of the devs for MultiBit HD.


Help------ -dumpprivkey gives key connected to different address

You can install a lightweight wallet to your phone, this will work much faster than since it doesn't need to download the full blockchain and verify it.
Then you can import the private key and you will be able to use your bitcoins.

Some options:

electrum.org
exodus.io
Mycelium
GreenAddress

Not all of them support all operating systems but together they cover Windows, Mac, Linux, Android and iOS.


Tracing SegWit transaction via blockchain.info

This is not a segwit transaction, this tx starts with:
    01000000048583473E2F1AE32B7C4397D85B041DA5BC75C7CCD3CE9EAD9374EDB27FEE888100000000FC...

and translates to:

VERSION
 01000000
TX_IN COUNT: hex=04, decimal=4
 TX_IN[0]
  TX_IN[0] OutPoint hash  8188EE7FB2ED7493AD9ECED3CCC775BCA51D045BD897437C2BE31A2F3E478385
  TX_IN[0] OutPoint index hex=00000000, decimal=0
  TX_IN[0] Script Length  hex=FC, decimal=252
  TX_IN[0] Script Sig     ... <sig>

whereas a segwit tx would look like this (marker and flag):

VERSION     01000000
SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01
TX_IN COUNT: hex=04, decimal=4

As the sigs are part of the Input section of the tx, one can derive easily, that it is no segwit.

The tx has 4 multisig input parts, and 58 output parts. The output is mostly structured like this:

 TX_OUT[56]
  TX_OUT[56] Value (uint64_t)
  hex=F06B011B00000000, reversed_hex=000000001B016BF0, dec=453078000, bitcoin=4.53078000
  TX_OUT[56] PK_Script Length (var_int)
  hex=22, dec=34
  TX_OUT[56] pk_script (uchar[])
  002014B288DCA5D59CAA8868D1668C97C971E58AB3CCF10534AC567EA51AA8ABA299
    20: OP_Data32

--> This is an UNKNOWN script, but represents a BIP173 representation of a segwit address.

Two observations:
the amount of 58 outputs is certainly not a standard tx, and the many amounts of bitcoins, which are shifted around enorm. Looks to me like an exchange, which is shifting data between live accounts and cold storage... The script is indeed not a standard script (OP_DUP, OP_HASH, ...). The spending tx needs to meet this output data, and I am not quite clear how this condition can be met. So I think OPs question can be rephrased: "how to redeem a tx with a bc1 type segwit address". Maybe some experts here have a better inside view?


Is it possible to trace fraud committed via a service the bridges banking and bitcoin?

It may be feasible to trace amounts sent to the scammer's address, but it would require a lot of work, mostly communication to strangers, to pin an identity to an address. This difficulty would be further exacerbated by the employment of green addresses, mixing services, or simple holding.

Bitcoin is pseudonymous, meaning that tracing is only as easy as the person being traced allows it to be.

Bitcoin is not fungible, meaning primary that a "coin" is not uniquely identifiable. Rather, it's a distributed leger system, with value being subtracted from one account and added to another in each transaction.

The only traceable entities are thus the accounts receiving and sending, and the only relation to the physical world in each transaction is an IP address. Given the employment of an anonymizing service such as TOR or a lower-anonymity proxy, tracing that IP address to a physical location with a person is highly improbable (if you figure out how, I'll bet you could make a lot of money from governments!)

If you're still up for it, BlockViewer may assist in the tracing.

As an aside, it's pretty safe to say that any BTC sent would require nearly Herculean effort to reacquire. It would most certainly necessitate the involvement of law enforcement, which has not likely yet been trained how to deal with digital currency investigations. This highlights the importance of a third-party escrow service or a personal relationship between the buyer and the seller.


Block Explorer, which fields are reversed, and which are the same as in a raw block dump?

Hashes are displayed in little-endian when they are actually big-endian on the network, and difficulty bits are displayed as big-endian when they are actually little-endian on the network.

All other integers are little-endian.


Cannot connect to slushpool with bfgminer

I am also new to slushpool with bfgminer.
follow steps if it works to you .
sudo bfgminer

then enter url
stratum+tcp://stratum.slushpool.com:3333

then it will ask username with worker
username.worker

then password
thats it .


Just because someone has made something and given it a name doesn't mean that it isn't utter garbage.  Don't trust any review or analysis from anyone that can't give you clear and well reasoned list of criteria that it is necessary and sufficient for a difficulty update algorithm to achieve.

Some of the fad options that altcoins blindly copy don't even achieve the basic property of achieving the target block interval when hashrate is constant.

Instead they seem to obsess about falling back to the nominal rate when hashrate suddenly spikes, ignoring that slow blocks are a safe failure mode and completely failing to consider the security side effects of their decision. We've seen at least a few hyped difficulty update changes lead to actual attacks, not just theoretical weaknesses.

I have no doubt that its possible to make something that is pareto-superior to bitcoin's non-overlapping rectangular window, but I am equally sure that essentially all the other things you see hyped fail to do so. This is unsurprising because instead of starting with a meta-analysis to understand what properties are useful, they all seem to have been created by changing things and analyzing only one or two properties (or not even analyzing things at all).

Keep in mind the primary purpose of most technical changes in most altcoins is to create marketing bulletpoints that can be used to convince unsophisticated speculators to pay for the altcoin.  This marketing requires a lot of hype-- far in-excess of whatever hyper a theoretical 'perfect' difficulty update would deserve-- but not a lot of substance.


Can a miner just download the blockchain once and then delete it (don't have a full node)?

If miners delete the blocks data, someone can fool them by sending a transaction that spends money it shouldn't be able to. In principle, some of them could do that and trust the other miners to validate transactions, but the more people do that, the more the whole network is vulnerable to fraud.

The same can be said for non-miners. If you don't run a full node, you're not actually running Bitcoin, but trusting people that run it to verify transactions for you.


The owner of 1E9b2CvbB9pKT617zNbxoVNH65XqMjarPX is likely the same person as the owner of 1JXstXTaeg6eH3wCXvdC7TYSA8ntWAsPc8. A single user can have as many addresses as they want. When the sender wished to send .0001 BTC to 121orLQW2LanEtso2htwZSfZ3vV4toLKt6, two of their addresses were emptied to meet the required amount.

The inputs sum up to .00020782, but only .0001 is sent to 121orLQW2LanEtso2htwZSfZ3vV4toLKt6. The remaining .00010782 was used as a miner's fee, and went to the miner who mined the block this transaction is included in.


According to blockchain.info, not only has the recipient received the funds, but they appear to have already spent them again.


There is a chance that someone took your coins by hacking into your computer and copying your wallet.  However, if this is the case, you should be able to load your wallet and see the out payment transactions.

Alternatively, search your payment address at BlockChain.Info  BlockChain.Info is possibly the best block explorer for bitcoin.  It's a good place to do research.


What does this sentence (on ability to broadcast a valid transaction and transfer balance) mean?

It means both. The power to transfer your Bitcoin to another address is the same as owning a Bitcoin. You can transfer your Bitcoin if and only if you own it.


C++ source code for bitcoin miner software?

Two popular Bitcoin miners, BFGMiner and CGMiner are open source and written in C++. The source code repositories for both are linked.


listunspent bitcoin core command returns the address as String while getrawtransaction addresses are array

This is a historical oddity.

In the past, Bitcoin Core would report the list of participating keys in a multisig addresses by listing the addresses for those keys. This was both confusing (addresses and keys are distinct things), but also unreliable, as the full public keys were not always knowm (when P2Sh was introduced). You can  safely assume you won't see multiple addresses in any output to an address created in modern times.


What is the difference between Bitcoin Core and UASF?

Correct, core and UASF groups are both Segwit supporters (as are Segwit2x supporters).  Both core and UASF are against 2x.  UASF is just an attempt to force segwit if miners had rejected it (miners did not reject). I'm not really sure how they expect UASF could have been successful without hash power if miners had actually rejected Segwit.

I've seen some core supporters argue that UASF was reckless (would have disrupted non-Segwit nodes), so though the chains they support today are the same, the groups are not perfectly in alignment.  More details here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

You can see who supports the New York Agreement (Segwit2x) here:

https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

As stated in the link, they represent (at the time of the agreement):

58 companies located in 22 countries
83.28% of hashing power
5.1 billion USD monthly on chain transaction volume (likely larger now with higher price)
20.5 million bitcoin wallets

Most notable from my perspective are Bitpay, Coinbase, and the majority of miners.

Here you can also find those who supported the original Hong Kong Agreement from a year ago:

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

The original HKA failed.  Many who signed onto the HKA (e.g. Adam Back of blockstream and the core contributors) seem strongly opposed to 2x today, which is most of why it failed. The Segwit2x of NYA is in some ways an attempt to bypass those who agreed to pursue 2x a year ago but who actually ended up fighting it.

Opposition (the core devs, who effectively want to retain veto power) argue that giving in to miners/businesses gives them too much power.  Some from the 2x crowd argue blockstream & core are attempting to block capacity increases to force users into the lightning network. It's all rather political and there isn't much trust.  Ill will is taken for granted in most debates.

The HKA was a bit less committal ("This hard-fork...will only be adopted with broad support across the entire Bitcoin community") which I suppose is how the core team can say they aren't technically violating their word.

My impression is that these particular core HKA signatories are the primary driver of "the Bitcoin community" that opposed.  When it became clear that core had no intention of pursuing 2x and were actively fighting it, the initial HKA compromise no longer seemed relevant or in good faith -- i.e. activating Segwit would sacrifice any near-term opportunity for a meaningful capacity increase. Blocking Segwit became a tool to fight for a capacity increase. All this further fanned the flames of the rather toxic scaling/capacity debate.

Here's a list of companies tracked by coin dance that support or oppose segwit2x, though the data is a bit sparse. As of today 67% are neutral, 24% support, and 9% oppose. I don't recognize many of the "no" voting companies other than blockstream. They give the option to weight the votes by total web traffic (not perfect but gives some indication of relevance), bringing support to 44%, neutral to 56%, and opposition to nearly zero.

https://coin.dance/poli


Error loading wallet.dat: Wallet corrupted

Version 0.6.0 introduced more strict validity checks on the keys when loading a wallet, to prevent silent further corruption. It seems like you have a wallet where one or more keys are corrupted (the private and public one don't match, for example). You can try moving the funds away using an older version, but there is a chance that will fail.

I intend to add a sort of "recovery mode" in 0.7.0 for situations like this.


Is there a correct way to refer to "orphan" blocks?

Pieter Wuille suggests extinct blocks:

  The first is perhaps best called extinct blocks. These are blocks that were produced by building on an block that is no longer the active tip of the chain. Some nodes may have considered it to be the best block at some point, but they switched to another chain which does not contain the relevant block anymore. They are valid, verified, and their ancestry up to the genesis block is fully known - they're just not currently 'active'. They are sometimes called stale blocks (typically in the context of mining software realizing it built on old data) or orphan blocks. The latter name [orphans] originates from the fact that payouts from extinct blocks are denoted as "orphaned" in the reference client (referring to the fact that their coinbase transactions are now orphaned).


Have a bunch of wallet.dat files. What alt-coins do they have (and may be how much)?

Just open each file and look for name"

the address will be after that.


What are some good online Bitcoin wallets based on client-side security?

Yes there is such a service which provides exactly what your looking for it is called StrongCoin


On the bitcoin wiki, there is rather complete list of validation checks that are done by the Satoshi client: Protocol_rules.

There is a section specifically about transaction checking as well.


How to add handwritten key or code to a wallet

How do I get this code or key onto a wallet or USB?

Wallet

By USB I guess you mean a hardware-wallet like the Trezor etc.

Choosing a wallet is an important step, I assume you have looked into this and are aware of the dangers of using some types of wallets and are aware of the need to never give any helpers your private-key or the password to a wallet.

There are several ways of writing down a private-key and there are mnemonic-word based systems for saving private-keys (the private-key is derived from the phrase). You should find out which sort of private-key or seed-phrase you have and make sure your chosen wallet supports it.

The general process is to first install the wallet, some wallets are full-nodes and take several days to synchronise with the Bitcoin network.

Private key

Once you have a wallet installed and ready for use, you find the menu option for importing a private key. You can then type the key into the wallet. It should then show the amount of unspent bitcoin for addresses derived from your private key.

A private-key in Wallet Import Format (WIF) might look like 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

A private-key in Hexadecimal format might look like 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

Seed phrase

A seed phrase might look like witch collapse practice feed shame open despair creek road again ice least. They usually have 12, 18 or 24 words chosen from a list defined in BIP39. Not all wallets used BIP39 though.

Wallets such as Electrum support this seed-phrase system which can be used for "wallet recovery".

Useful links:

Wallet Import Format (WIF)
Seed phrase
Wallets
What type of Bitcoin wallet is more secure than others?
Types of Wallet
Why doc says importing private keys is so dangerous?


Can I somehow force bitcoind to do decomposition with getblock?

By looking at the source code here

https://github.com/bitcoin/bitcoin/blob/master/src/bitcoinrps.cpp
https://github.com/bitcoin/bitcoin/blob/master/src/rpcblockchain.cpp

and comparing it to the code in the pull request in the question

https://github.com/bitcoin/bitcoin/pull/886/files

it seems like it is NOT possible in the code today. Oh well.


What is the current size of txindex folder when txindex=1 set?

27GB as of 2020-06-14

You yourself can check this via going to .bitcoin/blocks/index folder. Where .bitcoin folder is usually hidden folder on home when using linux.

It depends if you have pruned than the index folder might appear less in size. As of today my index folder is 105.4 MB since I've prune=1000 and it would remain the same in future as well.

Our question is answered here as well. Please check comment by @anonymous


Which wallets can send to native segregated witness output addresses today?

Electrum 3.0+ allows user to create a segwit wallet with native P2WPKH (Bech32 encoded) addresses starting with bc1q.. for Bitcoin mainnet.
When creating the wallet, select first "Standard Wallet" (as opposed to multisig) then "Segwit Wallet".


One of the fundamental principals of cryptocurrency is to be able to operate without the need of a trusted central entity.
I can't see how a transaction can be cancelled or reversed without involving a trusted central entity to arbitrate the transaction.

However we also have cryptocurrency like Ripple. In my opinion Ripple is not a cryptocurrency because of the centralized nature, but well what do I know.

Maybe in the future some genius will discover a method to implement this without a central entity :)


Using bitcoins JSON RPC, how can I confirm a transaction I published?

You can use the listtransactions JSON-RPC call to get the complete list of transactions that have to do with your addresses. This includes both sends and receives. You can filter for the transaction you're looking for by the category (should be "send"), address, amount and time. The txid and confirmations in this RPC call should be what's actually included in the blockchain and can be relied upon.

For reference, here's what the RPC call looks like:

[
{
    "account" : "",
    "address" : "1ENnzep2ivWYqXjAodTueiZscT6kunAyYs",
    "category" : "send",
    "amount" : -0.00040000,
    "fee" : -0.00010000,
    "confirmations" : 34055,
    "blockhash" : "000000000000000019313300fa20943b3974a97c1da2de6de13ea1281f77097f",
    "blockindex" : 414,
    "blocktime" : 1404861981,
    "txid" : "8a1f0f07fb397b2aa0e77995723f2dac9aee7df63a6f05a7db7d168d62a60f94",
    "walletconflicts" : [
    ],
    "time" : 1404861981,
    "timereceived" : 1412296394
}
]


How can I get the confirmations of a transaction using bitcoind?

Like it says, gettransaction can only return info on transactions which are part of your wallet, i.e. those which send coins to or from one of your own addresses.

Normally Bitcoin Core doesn't keep track of any data on non-wallet transactions, but this can be turned on with the -txindex option.  (Building the transaction index for the first time will also require you to reindex the entire blockchain with -reindex, which will take several hours to days and a fair amount of extra disk space.)  With this turned on, you can use getrawtransaction with any past transaction, wallet or not; if you want human-readable output, including number of confirmations, add true after the txid.


Yes, this is a common process used by scammers. It ends up in you paying them lots to withdraw your money that has never been yours without receiving even 1 cent from them.
Don't write to them but seek help from your local authorities.


How many shares need to be mined before a block is released?

When mining in a pool you are simply looking for simpler blocks than those that are used in the network itself. Let's say you are mining in a pool that counts difficulty 1 shares. That means to find share you have to complete 2^32 hash operations. Since difficulty is defined as the ratio between the current target and the maximum (as in easiest) target, each increment in the difficulty doubles the number of hash operations you'd need to find a share. Hence the probability of a share also being a block is:

share_difficulty / block_difficulty

since the current difficulty (29th of May 2013) is 12'153'411.7098 the chances of a share of difficulty 1 being a block is 1/12'153'411.7098, and the expected number of shares until a block is being found is again 12'153'411.7098. Notice that in the last step we are talking about an expected number of shares. As mining is a random process there is no guarantee of finding a block in finite time.


What does influence Bitcoin price so much?

The market is full offer and demand based. People sell, price goes down. People buy, price goes up.

The amount of people with new capital entering the market push the price up hard. Harder than the new Bitcoins, obtained through mining, are pushing it down.

You have to realize that people have to choose to sell or buy Bitcoin. The amount available is called "market depth" and it causes "market liquidity". http://mtgoxlive.com/ Is a display of "market depth". You can mouse over the blue and orange lines to see how many bitcoins must be bought or sold to bring the price to a certain point.

Then you will see that the 4684 bitcoins must be sold (at prices offered by others) to bring the best-available price to 550 Euros. To bring the price up, 3687 bitcoins must be bought to bring the best available price to 750 Euros.

Exchanges, real-time bids on Bitcoin for Euro or Euro for Bitcoin, are a method to find the "right price" of Bitcoin. Real-time exchanges fluctuate in the real world a lot too. It doesn't really work that well. But it succeeds in creating an acceptable price (if someone wishes to buy it for that price, it's worth that), and that's why the other Bitcoin are affected. People accept the spot price set by the people that use the exchanges.


a few questions about how HD wallet works

1) ...How's my total UTXO calculated?...

Each node calculates it's own UTXO set, there is no single 'global UTOX set'. You may own some subset of the UTXOs, but there is no pooling. If you receive payments to the same address more than once, each one will be it's own UTXO.

  2) ...If all public addresses have their own UTXO, then the wallet has to choose a number of UTXO as inputs for each new transactions. Is it how it works?

Yes, and each wallet may perform coin selection differently when authoring a new transaction. Some wallets even allow manual selection when sending transactions.

  3) Do we use master private key to sign every transaction?

No, each UTXO can only be signed by the child private key for that particular address. In the case of an HD wallet, the xpriv key is used to derive the child private key for each address. Those child private keys can then be used to sign transactions.

Each address derived by an HD wallet looks just like any other bitcoin address, there is no way to know it came from an HD wallet. So in order to spend the UTXO, you need to present a signature made by the private key of that specific address. The network does not know that your address was derived from an xrpiv key, so if you use your xpriv key to sign the transaction, it will be invalid.


Why can't we set fees to a fixed amount say 0.005 BTC?

I was also giving the problem a bit of thought, and here are some conclusions I reached:

It is impossible to set a fixed fee once and for all, as one does not know the volume of transactions that will appear in the future, nor how big an exponent of Bitcoins will be a "common sight" (before Bitcoins became popular, someone paid 10kBTC for a pizza for example). So the fee would need to be adjusted over time, a bit like difficulty.
Percentage of transaction amount would be harming the people owning large amount of Bitcoins in one address, as in order to spend some of their Bitcoins, they need to send the rest back to themselves. This would encourage people to spread their Bitcoins over many addresses, creating an accounting mess at times.
Calculating the fee based on real-world value of 1BTC would be too hard, as it would require a lot of knowledge form outside the network.
Calculating the fee based on current difficulty can be slippery for transactions sent around the difficulty adjustment block.

So in general, the current way of calculating the fee might not be that good, but nobody smart enough has come up with anything better.


What's stopping an infinite number of altcoins with the same protocol from appearing in the future?

Nothing stops this at all.  You can start your own right now, removing the 21M limit or adopting whatever rules you want, and mine as many coins as you like.

Likewise, you can sit down at your printer, and print lots of $100 bills with your own portrait, and invent whatever rules you want as to how they can be spent.

The question in both cases is whether anyone besides you will want to use them, and be willing to exchange them for goods or services.  You'd have to convince people to use them, that your rules are such an improvement over the existing ones that they should switch.   If they don't, then your new coins or bills have no real value.

So there's nothing stopping an infinite variety of altcoins from appearing; but probably only a few of them will be adopted by anyone.


What will happen if transactions are being generated by multiple person with same one private key?

There is no "the mempool". Each node has its own mempool. So in your example, each node would receive each of the transactions, possibly in a different order, and at different times. It is physically impossible for all three transactions to reach every single node at the exact same time.

If we assume that none of the transactions signal for RBF and all of them pay the same fee and it is sufficient (i.e. above the minimum relay fee), then every node will accept into its mempool the first transaction it sees. Due to network latency and physics, each node will probably accept a different transaction because they will arrive at slightly different times. So some nodes will accept tx1, some tx2, and some tx3.

Miners will then choose the transaction that they have in their mempool. If their node's mempool accepted tx1, then tx1 will be in their block. If tx2, then tx2, and if tx3, then tx3. It is purely whichever one arrived at their node first.

Now let's suppose the only thing different is the fees. Still no RBF, but everyone has paid a different and still sufficient fee. Then the same thing pretty much happens. The vast majority of full nodes use Bitcoin Core which does not implement full RBF. So a conflicting transaction that pays a higher fee will not be accepted. This is for anti-DoS and anti-spam reasons. In order for a transaction to be accepted as a replacement, the original must signal that it is replaceable.

If one of the transactions signals for RBF and one of the other two transactions pays a higher fee, then we have a more interesting scenario. For the sake of example, lets say that tx1 signals for RBF, and both tx2 and tx3 pay higher fees than tx1. Then nodes that accept tx1 will replace it with the first one that they see of tx2 or tx3.

So in this case, in the end, most nodes will end up with either tx2 or tx3. And the miners select from either tx2 or tx3, depending on what their node sees, which depends on which arrived first.

If tx1 again signals RBF but this time only tx2 has a higher fee (tx3 has a lower one, but still sufficient), then nodes that receive tx1 that then receive tx2 will accept tx2. Nodes that first received tx3 will reject tx1 and tx2 as double spends. The rest plays out as before with tx2 and tx3.

If tx1 and tx2 signal RBF, and tx3 has a higher fee than both, then ultimately most nodes will end up with tx3. Nodes that received either tx1 or tx2, and then received tx3, will replace with tx3. If tx2 has a higher fee than tx1, then nodes that received tx1 then tx2 will first replace with tx2. Once they see tx3, they will replace with tx3. Ultimately, most nodes will have tx3 so tx3 is most likely to be mined by miners.

If tx1 and tx2 signal RBF, but this time tx3 has a lower fee, then we could have a repeat of the first scenario, or a race between two of the transactions. If tx1 and tx2 have the same fee, then it will be a race between all 3 transactions as no transaction outbids the other so none of them can be replaced. If tx1 has a higher fee, then nodes that received tx2 will likely replace with tx1. And vice versa. In this case, it becomes a race between tx1 or tx2 and tx3. Nodes that received tx3 first will not replace it because it does not signal RBF.

Lastly, if all 3 transaction signal RBF, the transaction that is most likely to be mined becomes the one with the highest fee. Again, if all 3 have the same fee, then all 3 are eligible as in the first scenario. But if one pays a higher fee and can replace the others, then that transaction will become the one that is in most node's mempools will be the one that pays the higher fee.

If any transaction does not pay enough fee, then it doesn't get relayed and it becomes a race of the other transactions. If two transactions don't pay enough fee, then the one that does becomes the one that is mined.

So the transaction that gets mined depends on whether any signal RBF, which signal RBF, the transaction fees, and which transaction miners have.

  What happens if people compete by repeating infinitely resending their transaction through the -zapwallettxes option in Bitcoin Core?

-zapwallettxes doesn't make a difference if the transactions pay enough fee. If the transactions don't signal RBF, it doesn't matter. -zapwallettxes only affects your local Bitcoin Core wallet (not even the node, it does not remove the transactions from your node's mempool). So doing this has no effect.


Why is such a large int (uint32) used for the transaction version field

What was the rational for using such a large integer?

Because Satoshi did not care about it. Bitcoin transaction serialization is not optimized for size.

  Could this be reduced with a new block version?

No

  Could this be done without a hard fork?

No. But you can implement new way to serialize data on disk and on network and encode/decode transaction contents on-the-fly. In fact nobody cares about these bytes.


Is it possible to track physical objects on a blockchain?

I forget who once said this, "If you think you need to use BlockChain technology, you almost certainly don't."

BlockChain technology is designed to show proof of ownership via a proof of work mechanism that ties an expensive-to-run algorithm to a cryptographically secure chain of transactions.

If your system seeks to track ownership of objects where ownership changes regularly, and you need to prove ownership, perhaps a BlockChain solution might be applicable.  However, if your objects don't regularly change ownership, and you're simply looking to track geographical position, I would recommend some other data storage system, such as a typical relational database.


Does outbound port have to be open to make an Json-RPC call

The RPC server doesn't care what source port the request comes from, and it doesn't need to make any extra connections back to the client on that port or any other.

However, a possible cause for your trouble is that the shared webserver's firewall blocks outgoing traffic with a destination port that is not on their whitelist.  (That may be what is meant by "having specific outbound ports open".)

The fix would be to change the RPC server configuration to listen on some other port which is allowed  as a destination port by the shared webserver.  The most obvious choice would be port 80, if the RPC server machine isn't also running an HTTP server.  Otherwise, you can try various commonly used ports to find one that is allowed by the firewall and not already in use.


Are transaction fees required now? Is there any way to avoid them?

Use Send Custom for full control over fees.

Click Send Money tab, then on the left menu under Transaction Type click Custom.

This URL might get you there.

https://blockchain.info/wallet/login#send-custom


Bitcoin protocol / algorithm scalability

1) It's not clear why you think every client having to download the entire block chain is a scalability problem. Pruning currently doesn't take place but it should eventually be possible in theory. Storage space is growing at a much faster rate than Bitcoin is.

2) To validate a new transaction, the only transactions you have to look at are the inputs to make sure it validly claims them. Presumably, you already know every currently-valid transaction output already. You have to check a block in order to accept it anyway.

3) This is the nature of the way Bitcoin prevents double-spending attacks. It's because Bitcoin has adopted a "no central authority at all" approach. Nobody, as far as I know, knows a way to do instantaneous transactions without a central authority. (Consider, for example, if a natural disaster splits the Bitcoin network into two halves and each half sees a conflicting transaction. How would you know?)


How OP_CHECKSIG knows the source of sig in pay to pubkey hash transaction

But how the script interpreter knows the sig the signature of the
  previous transition hash, what if the sig is the signature of some
  other content?

It also compares the signed data with the transaction hash itself. In general, this is how digital signatures work. If the data isn't signed by the right key, and data hash doesn't match, then the signature is invalid. See src/script/interpreter.cpp L#1264.

This verification process ensures two things:
1. The person has the private key which corresponds with the public key provided.
2. The data has not been tampered with.


Bitcoin confirmations represent the number of blocks in the block chain that have been accepted by the network since the block that includes the transaction.

In simpler terms it represents the difficulty of a double spend attack. With zero confirmations no proof of work has been done, so you can't tell if anyone considers the transaction valid.  Even with a single transaction it is possible for an attacker to pre compute a single block.

With zero or even one confirmation a double spend is very possible since the next block that is solved may confirm a different block instead of the one that has the transaction.  That different block my show the coins being spent elsewhere.  The odds that a double spend has occurred gets exponentially smaller with each confirmation.

An attacker must match the power of the entire bitcoin network to keep up with block creation so as time goes by it becomes increasingly difficult to forge a transaction.

It is generally accepted for most transactions that 6 confirmations represent enough security to assure the transition is valid.


Correlated raw transactions' input/output chaining

I think your business process is confusing the issue. I'm going to assume that the "business" side of this also wants to take a cut of the transaction or it wants to delay paying the charity and that is why this has become more complicated.

There are a number of considerations not least the fact that you are using one input to pay the merchant, and the change to pay the freight, and the change of that to pay the charity.

What you are concerned about is the inability that you have built-in to pay the one party because of a preceding ttransaction, but that's your business process at fault not the Bitcoin protocol.

You should also consider the minimum payment amount and the eventual network fee, neither of which are %age based.

These are not mentioned and in fact by making two (or possibly four) transactions you are incurring up to 4x the bitcoin network transaction fees.

This is one of the main reasons why (from a business perspective) you should not split the transactions up ie it is more expensive and who is going to wear the costs? The charity? the merchant? the freight? You?

Can I suggest also that you have misunderstood the "confirmations" as something other than your transaction being included in a block. When a transaction is requested by a peer prior to it being included in a block - the peer validates the transaction independently, and if for any reason it is not good it is rejected. This is NOT the process of "confirmation".

All peers in effect will do the same validation to your transaction as it propagates through the network (which BTW is extremely fast).

Confirmation on the other hand is when the transaction has been included in a block, and the only time this becomes an issue is if there is a fork in the blockchain. But even then you still can rebroadcast a transaction if the "other fork" becomes the final one provided the basis on which it was made is good.

The point I want to make is that you are placing too much emphasis on confirmations for transactions that you yourself have created, and then wait until someone else confirms what you already know to be true, and this seems completely pointless.

Perhaps you can expand your question to explain the "business reasons"?


Do you offer both Bitcoin and PayPal/other on your website? If so, offer them some discount, say 10% off, if they use Bitcoin. Tell them that it is due to lower processing fees. With some monetary incentive, you will convert some of your customers over.

If you offer only Bitcoin, put some link in a visible page stating something like "why only Bitcoin?", then bring them to a page in your FAQ where you explain your reasoning to use Bitcoin - lower development cost, lower processing cost, no charge-backs, freedom from third party companies, etc. etc.

Be sure to link to some accessable material for newcomers - for example, We Use Coins, or some materials from Bitcoin Wiki on Introduction.


What impact could the patents applied for by Craight Wright have on Bitcoin development if granted?

Searching the http://patents.stackexchange.com site, I found a question that linked here:

http://ask.metafilter.com/216885/What-happens-if-an-opensource-app-intentionally-violates-a-software-patent#3129948

  An open source program can infringe a patent just the same as a
  commercial one. There is no requirement that the infringement be for
  profit, since infringement may consist of making, using, selling,
  offering to sell, or importing the invention. 35 U.S.C. § 271.
  Infringement may be direct (i.e. the author making the software) or
  indirect (e.g. the author distributing it to others intending that
  they use it in an infringing manner).

  What's more, by copying a program knowing that it likely infringes a
  patent, the open source author may be liable for willful patent
  infringement. That carries with it the possibility of treble damages
  and an award of attorney's fees and costs. 35 U.S.C. § 284.

So yes, it appears as though Bitcoin developers could be held liable.

The article also continues to state that it is often not financially feasible for patent holders to go after open source software, since software is global but patents vary country to country.  Also, there are not necessarily assets to be won from open source developers.

Personally, I feel that Craig Wright has been applying for patents not to target Bitcoin, but the growing blockchain industry.  The banks and financial institutions adopting blockchain solutions do have assets that can be easily won (or settled) with patent suits.

DISCLAIMER: I am not a lawyer, and am way out of my element with this answer :)


The 12, 18, or 24 word mnemonic that you have (colloquially referred to as the seed) is a BIP 39 mnemonic. This encodes a 256 bit number which is then used to derive the private keys in your wallet.

All of the private keys in your wallet are derived using the method described in BIP 32. This allows for private keys to be derived from a fixed seed (which is encoded by your BIP 39 mnemonic) and to be done so deterministically, i.e. the same keys are always derived.

So when you restore a hardware wallet or any other wallet that supports BIP 39 and BIP 32, you are really just setting a fixed seed which is then later used to derive all of your private keys.


Implementing a Blockchain at the very basic level?

Bitcoin Core is a software which maintains the blockchain ledger, You can obviously fork it and go through the entire code and make some changes to the source code to make your own blockchain (This is what every blockchain company is doing nowadays under the pretext of creating blockchain technologies.)

However, the above mentioned task is really time consuming. What you can do is study the workings of the bitcoin blockchain, and simulate them using a more popular database. There have been cases where people have sold their 'blockchain' technology with SQL running at the back. Blockchain is basically a database(highly replicated) and you shouldnt confuse it with anything else.

So trying to make a blockchain from scratch will obviously take a lot of time in learning and then coding. If you are going with the "hidden SQL" blockchain , or for that matter any other db, you would need to make APIs to access the blockchain(just like bitcoin core). You dont need to have all the API's obviously, but the ones which are crucial for the blockchain you'll have to emulate.


Proof of work helps to solve the issue of transaction ordering: miners must create blocks that contain an order of transactions, and each block builds upon the last. Thus all bitcoin transactions are ordered, and this is required in order to resolve any potential transaction conflicts.

As an example: in the case of a double spend, which transaction is actually valid, and which should be discarded? A simple way to resolve this question is to say "the first transaction is valid, the second is not", but this solution requires the network to be in consensus regarding the ordering of all transactions.

In the case of email, ordering of messages is not critically important, so the inclusion of a POW has a slightly different primary function: to increase the cost of sending an email, in order to discourage spam messages.

    Then, in bitcoin, it seems natural that the senders engage in the proof of work instead of miners. Why it is not so?

Transaction ordering is important, but keep in mind that it is not trivial to reliably keep a decentralized network in consensus. Each transaction could include a proof-of-work, but this alone is not enough to give the transactions a well-defined order. Proof-of-work establishes a way to ensure resources were spent, but on it's own is not sufficient to establish an ordering of data.

Bitcoin solves this by grouping transactions into blocks, and each block references the one before it. You can imagine this as a sort of 'decentralized clock', where the smallest increment of time is one block. For transactions to function similarly, each transaction would have to reference the one before it, thus establishing an order. This would lead to a whole host of latency issues, higher rates of 'orphan transactions', potential for spam and DOS attacks, etc.


Which transactions are being submitted in the very first blocks of some digital currency?

You don't need to have transactions in order to mine. A block always contains at least one transaction, the "coinbase" transaction that says where the block reward should go, but it need not contain any others.


This is not really a bitcoin related issue.  As long as the exchanges have 100% reserves, they can always pay.  This means they need to have the sum of all balances of all customers on their own account.

The problem is that some exchanges apply a fractional reserve.  Using part of the users money to make investments or to cover operating costs.  You are correct to be worried for those exchanges bankruptcy should exceptional selling occur.

Kraken has a concept where they try to cryptographically prove their reserves https://www.kraken.com/security/audit

Not sure if other exchanges also have such a concept.


How do I check the checksum of a Bitcoin address?

The way Bitcoin checks a public address is using what is called Base58Check. While the Bitcoin Wiki covers Base58Check, I'll outline how it works in both abstract and technical terms.

The whole idea of Base58Check is to prevent invalid addresses. This is done by adding digits to the start (00) and end of the Base58 value (4 bytes of double SHA256 hash).

Add 00 to the start of Base58 value ie 00 + BASE58 ==> 00BASE58
Checksum = 1st 8 digits from SHA256(SHA256(00BASE58))

BASE58Check = (00)(BASE58_SHA256RIPEMD160_HEXADECIMAL_VALUE)(CHECKSUM) (parenthesis for visualisation only, all other data is correct in size, ie CHECKSUM = 8 chars)

The best way to visualize all this is with The Piachu's App


The value 1392447127 is exactly Sat, 15 Feb 2014 06:52:07 GMT in  Unix timestamp
check it here : http://www.onlineconversion.com/unix_time.htm

keypoololdest gives the unix timestamp of the oldest key in the key pool (which stores unused keys). This timestamp can be used to check if a wallet backup still covers all your used keys or a new one needs to be created.

At the latest, if the timestamp retrieved with keypoololdest gives a date younger than your youngest backup, you should create a new backup.


Is there a way to store and share a private key through blockchain?

A blockchain, in whatever form, is ultimately a shared transaction log that multiple nodes eventually agree on.

All information in the chain is public (to all participants of the system, not necessarily the whole world). Sharing secret information using a public log makes no sense: everyone would see the key.


What are Bloom filters and why does Bisq require them to be activated on my local node?

Bloom filters are a legacy way for a light client to query transaction data from a P2P node.
They are defined by BIP37 and we usually refer to these clients as "SPV wallets".

Why does Bisq care about Bitcoin Core being installed or not?

So that it can query transactions from localhost instead of scanning from some external source (with the well-known privacy leaks of bip-0037).

Why does it matter if it's "fully synced" or not before Bisq is started?

Considering the application, they may want to be sure to be to the latest Bitcoin state before taking any action on their own P2P network.

Why does it matter if it's "running in pruned mode"?

You'd be missing blocks and potentially some historical transaction data that Bisq might want to query for.


How would one go about creating a new alt-coin?

Try looking at these pages:

First, a "Complete Guide on How to Create a New Alt Coin" which, as the name says is a fairly step-by-step guide on how to create a new alt-coin.

Secondly, another thread started by someone who asked essentially the same question as yours: "How do you create an altcoin?"

The discussion which follows is a bunch of people discovering for themselves how to do it. Note that I haven't read through the entire thread (it's 15 pages long as of this posting), so I'm not sure if they ever successfully make an alt-coin or if they give up somewhere along the way. But it's an interesting read to see them figure things out and discover things together as a group.

And finally, A Psuedo [sic] Guide on how to Build an AltCoin, which doesn't go into as much detail as the Complete Guide linked above. In fact, it mostly just links to other threads on bitcointalk.org. That said, it may link to some information that answers some questions left from the other links.


2 confirmations means the transaction was included in a valid block and that block was continued by another valid block.
Option 3, although it should be next block (older than the one that contains the transaction) instead of previous block.


Do Lightning Channels have to be resolved before a certain time?

I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV

I think instead of "CLTV" you mean "CSV" (as in OP_CSV, BIP112).  As far as I know, nobody claimed that OP_CLTV would allow HLTC-style (Lightning) payment channels to stay open indefinitely, but that was definitely a claim of OP_CSV.

An additional prerequisite for indefinitely-kept open channels is segregated witness or another malleability fix.

Although it's a bit difficult to know what is confusing you without reading the source quote and context, I suspect that you're confusing the (1) dispute period for a unilateral spend with (2) a timeout.

When one party to a Lightning channel broadcasts either the current channel state or a previous channel state, there begins a dispute period where the other party can submit evidence proving that the channel was not closed in its current state (that is, it was closed fraudulently).  That evidence is cryptographic evidence that can be submitted to miners, who can add it to the blockchain and have it accepted by full nodes if the evidence is valid.

The dispute period is an arbitrary length of time from the point where one party attempts to close the channel by broadcasting a transaction.  However, there's no point at which either party is required to close a channel, so it's correct to say that channels can remain open indefinitely.  There is no timeout on the channel itself---there's just a timeout whose clock starts when one party decides to start closing the channel.


A question about transaction broadcasting and block creation

If I undestend the your question, you referer to the lockTime inside the  transaction and not the block timestamp.
The lockTime is a int value, and this value rappresent "When the transaction can be unlockd to an inputs" and not "When the transaction was published"
Lock time: Defines the first instant in which the transaction is considered valid and can be transmitted on the Bitcoin network, represented by an integer value between 0 and 500 million, assuming different meanings based on the value assigned, that is:

Lock time = 0: the transaction is propagated and executed at the instant of
creation.
0 < LockTime <= 500: the value is interpreted as a block height, ie the
transaction will be valid only after the block with height
equal to the lock time value has been published.
Lock time> 500 million: the value is interpreted as a unix timestamp and
therefore the transaction will be valid only after the
date represented by the lock time value.

If you mean if the transaction has a timestamp, the answer is two:

Within the structure the transaction does not have a timestamp, but
rather a lock time.

The transaction could have an insertion moment in the block, which
depends on the block, because it is he who holds the timestamp as a
value.

A real use case:
  My transaction has a block timestamp equal to 8/23/2019, 2:08:43 PM GMT + 2, this represents the time in which the miner started the cryptographic challenge, and it is the instant in which the miner has also taken into consideration my transaction including it in the block.
My transaction has a lockTime of 0 because it is an immediate execution transaction.
No one excuses that my transaction before the block was published was ALSO inside some other block with a slightly different timestamp
If you want have turned a detailed explanation of what and how a transaction works, I recommend this reading on bitcoin book
Update from Bitcoin Dev
In the comment, Pieter Wuille in the comment below post the following answer and explain that my answer is wrong, and a very precise answer is reported below

The nLockTime of a transaction determines the earliest possible time
it can be included in a block. It is illegal to have a block which
includes a transaction whose locktime has not passed yet. There are
however mechanisms to forcing a transaction output to be only be
spendable with a future transaction which has a certain locktime - the
net effect being that this output can be included on chain, but
transactions spending it cannot until such time passes.


What is the age of the oldest known Bitcoin core developer?

I am unsure of how old these core developers, but 2 that come to mind are Gavin Andresen and Mike Hearn. Hearn left recently  due to personal conflicts. (story here)


Why is a "first seen" rule is used to pick a side in a honest split, instead of deterministic criteria?

for example, the one with the "best hash" (number further away from the difficulty cut)?
Deterministic criteria like that would allow the entire network to quickly know which block wins, and everybody would then build on top of that block. Much less hashpower would be wasted on the dead branch.

If you see that you are very likely going to win on account of the deterministic criteria, whatever it is,  then you can withhold announcing your block while you attempt to form a successor and announce your prior win if you see a competing block show up. This would give you an advantage over other miners who behave honestly (and even if everyone does it, it would continue to give larger miners an advantage over smaller ones).


How to update and older version of electrum on ubuntu 17?

how would I go about updating electrum? What command would I use to
  update?

There are couple of ways to do it:

If you downloaded the official package (tar.gz), you can run electrum from its root directory, without installing it on your system; all the python dependencies are included in the 'packages' directory. To run Electrum from its root directory, just do: ./electrum
There is also PPA package repository, but I think they didn't update it.
I've a shell script, this script check the github source, download the last version and save the backup of an old wallet. You can find it here.

  where are the electrum files installed that contains my private keys
  and wallet?

On the Linux machine, there is the folder ~/.electrum which contains your wallet, configs and other.


Does the first transaction to hit the network win and the later one just never get confirmed?

Almost however it's not as simple as the "first" transaction, but it is essentially a race.
When a new transaction is broadcast to other nodes it enters what is known as the mempool. Using the phrase "the mempool" can be confusing since there isn't a single mempool, every node has its own mempool and it may not be the same as another nodes mempool.
In your scenario, two identical wallets different sides of the world, the one that broadcasts a transaction with a higher fee may "win", or the one that broadcasts to nodes that are better connected for propagation across the network may "win".
Once the transaction is in the mempool and other nodes know about it, you will likely receive a "missing inputs" error when trying to broadcast inputs that have already been spent. The transaction does not have to be confirmed in a block in order for the double-spend to be noticed; it only needs to be in the mempool. Some transactions can sit in the mempool for hours or even days if network use is high and the transaction fee for that transaction are low making it important that transactions in the mempool are checked for double-spends.
In any event a transaction does not have any degree of permanence until it is confirmed in a block. Even with 1 confirmation a transaction may not be permanent in the event of competing longest chains, the losing chain will have orphaned blocks.
Back when bitcoin was younger many people would wait for 6 confirmations before considering a transaction permanent.  Today a few confirmations is likely enough for most transactions to be considered permanent.


What happens if I buy BTC from an ATM, but the transaction never confirms?

In this case, you would need to contact the ATM operator / service provider, and provide them with some proof of your purchase and the failed transaction. When completing your interaction with the ATM, you should receive some sort of receipt that details this information, though the exact specifics will likely vary from one ATM to another.
If you are running a full node, perhaps you could find the transaction which was supposed to pay you in your node's mempool, and then save it to be rebroadcast in case of an extended period of non-confirmation.
But I think that in most cases, you will just need to contact the customer service department of the ATM operator, and request that they complete the transaction.


While I haven't verified the signature, upon inspection of the encoding I think I can see what is wrong. Let's break down the scriptSig briefly and I'll show you:

8a (total number of bytes to follow)
46 (the signature is 0x46 bytes long *THIS IS WHERE THE ISSUE IS*)
30 (compound DER type)
44 (0x44 bytes following)
02 (integer type)
20 (0x20 bytes long)
3c8aaa41ae647149f70ce24f73109e99d59d7e54a5d854239943358d581e9f83 (R value)
02 (integer type)
20 (0x20 bytes long)
6336cb57c00bb78f46c881b3d6bb2ed76dc652eedf36064ae022ea4ae3ba3b10 (S value)
01 (SIGHASH_ALL sighash type)
41 (length of public key is 0x41 bytes)
049d0f70eed85345ca5c1c04563bed19608562c37d644061785a836e8f199155f2818a1e2661f9ed501d8f906611892099a9de5a7ea9f641ecb4dd75bbb63c2d5a (public key)

Now I've highlighted the length of the DER encoded signature as the issue - 46. This should be 47. The reason is that that length is actually supposed to be the length of the signature plus one byte for the sighash type. Unlike normal DER signature produced by OpenSSL, Bitcoin requires the sighash type to be appended, in this case 01 for SIGHASH_ALL. You can see the 01 byte present. But you haven't updated the length. In the valid transaction below it, on the other hand, you can see the length is 47 despite the fields being the same length.

So try updating the 46 to a 47 and see if it works :)


What is the 25th word in a mnemonic seed when used on a ledger nano s?

From BIP39:"A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead."

The passphrase can be added in the transformation from the mnemonic phrase to the seed. It is not added IN the mnemonic but in an other point of the procedure.

A consequence of this is that:
"The described method also provides plausible deniability, because every passphrase generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available."

The passphrase is a second parameter in the "generate the seed from the mnemonic" procedure. If you don't provide it the procedure assumes that the second parameter is "".


How are transactions invalidated by nodes when both parties are offline in a Lightning Network?

AFAIU, if you have open lightning channels, you cannot go offline. You must be online in order to monitor the blockchain for old commitments. If you see an old commitment transaction, you immediately broadcast the punishment transaction, but you cannot do this if you go offline. So if you have open lightning channels, you must be online and if you go offline, you are trusting that the other person in the channel will not attempt to defraud you.


Is there someway to determine the current network fee from the bitcoin network/daemon?

Check the medium fee of last n blocks? I believe the transaction fee is currently not very variable. The reference implementation "ensures" that all transactions that are smaller than 1000 bytes, have all outputs over 0,01 BTC and have a large enough priority will be processed, regardless of the transaction fee. Otherwise 0.1 mBTC is paid for every 1000 bytes of transaction (rounded up).

The priority of a transaction can be calculated by [1]

priority = sum(input_value_in_base_units * input_age) / size_in_bytes


How can I find out if an e-wallet service uses a fractional reserve system?

There are two types of EWallets, hosted (shared) EWallets and hybrid EWallets.

With hosted EWallets, all the coins are shared (all customers funds are combined) in the host's EWallet.  Examples of this are Paytunia.com, Instawallet.org, EasyWallet.org, WalletBit.com,  as well as the online wallets with the exchanges, such as MtGox.com, Bitfloor, etc.

Hybrid EWallets are those that operate locally either from the browser (using Javascript) such as how Blockchain.info/wallet and StrongCoin.com operate or from a client like how Electrum (Windows, Mac, Linux, Android) or BitcoinSpinner (Android) operate.

With a hybrid EWallet, the private keys are kept locally but transactions route through the EWallet provider.  To protect from loss, the browser-based hybrid wallets store an encrypted copy of the data from the wallet online with the EWallet provider.  The provider doesn't have the password to decrypt the wallet stored with them and thus has no potential to spend your coins stored with them.

So your risk of fractional reserve exists only with the hosted EWallet providers.

One method these providers could prove they are not a fractional reserve would be to submit to sporadic financial audits.  None do this today.

Another option would be for the EWallet provider to treat each account as if it were a standalone wallet.  That way the blockchain would verify that the coins received have not been spent.  No EWallets operate this way either.

When multisignature becomes functional, this will likely be a security feature available from one or more EWallet providers.


How can I view in my shell, live, ALL activity my bitcoind is generating?

bitcoind -printtoconsole -debug

This will output an unreasonable amount of information and break your terminal, and not particularly help you with your sovereignty.


Say I received 10 bitcoins on a Bitcoin address I publicly advertise for donations. Anyone looking at the blockchain can put that address in a search engine and find me. Now say I want to use those 10 bitcoins to buy drugs. If the drug dealer's bitcoins are traced, they'll point right back to me.

Now I can create a lot of accounts if I want. And I can pass the 10 bitcoins I received through those accounts and then to the drug dealer. But likely because those accounts aren't used anywhere else, the trail would still lead right from the drug dealer to me.

Now suppose I put my 10 bitcoins in an account created just for me by a Bitcoin laundering service. And you and Fred do the same thing. Then the service sends my coins to Fred and your coins to me. Then I spend the coins I got on drugs. Now the trail looks exactly the same as in the non-laundering example, except the  trail leads straight to you instead of me -- a pretty good deal for me, not so much for you.


I have found a temporary solution:

BlockStore blockStore = new MyCustomBlockStore(NETWORK_PARAMETERS);
blockStore.getChainHead();

blockChain = new BlockChain(NETWORK_PARAMETERS, blockStore);

PeerGroup peerGroup = new PeerGroup(NETWORK_PARAMETERS, blockChain);
peerGroup.setDownloadTxDependencies(1000);
peerGroup.setBloomFilteringEnabled(false);
peerGroup.addPeerDiscovery(new PeerDiscovery() {
    private final PeerDiscovery normalPeerDiscovery = new DnsDiscovery(NETWORK_PARAMETERS);

    @Override
    public InetSocketAddress[] getPeers(long services, long timeoutValue, TimeUnit timeoutUnit) throws PeerDiscoveryException {
        final List<InetSocketAddress> peers = new LinkedList<InetSocketAddress>();
            peers.addAll(Arrays.asList(normalPeerDiscovery.getPeers(services, timeoutValue, timeoutUnit)));
            InetSocketAddress[] isas = new InetSocketAddress[0];
            return peers.toArray(isas);
        }

    @Override
    public void shutdown() {
        normalPeerDiscovery.shutdown();
    }
});

peerGroup.startAsync();
peerGroup.startBlockChainDownload(new PeerDataEventListener() {
    public void onBlocksDownloaded(Peer peer, Block block, @Nullable FilteredBlock filteredBlock, int i) {

        List<Transaction> transactionsList = block.getTransactions();
        int transactions = transactionsList == null ? 0 : transactionsList.size();

        long height = peer.getBestHeight() - i;
        //If the block contains transactions, it is likely to be complete.
        Log.e(TAG, "Downloaded block " + height + " with " + transactions + " transactions");
        blockUpdate(block);
    }

    private void blockUpdate(Block fBlock) throws IOException {
        //TODO: Update blockchain database with the full block.
    }

    public void onChainDownloadStarted(Peer peer, int i) {
        Log.i(TAG, "Started to download chain on peer " + peer);
    }

    @Nullable
    public List<Message> getData(Peer peer, GetDataMessage getDataMessage) {
        //Log.i(TAG, "getData from " + peer);
        return null;
    }

    public Message onPreMessageReceived(Peer peer, Message message) {
        //Log.i(TAG, "onPreMessageReceived (" + message.getClass().getSimpleName() + ") from " + peer);
        return message;
    }
});

In my case, I created a BlockStore that stores the blocks in a SQLite3 database. When I get the complete block, I overwrite the block register with the complete information (transactions, raw block, etc...)


Bitcoins not showing up in Bitcoin-Qt wallet

If your client is "32 weeks behind" then it hasn't yet received the transaction that sent the coins to its address. Once it is in sync, you should see  that transaction and a correct balance. If you are able to connect to the network, the client should sync automatically (though it may take many hours or even days, depending on the speed of your computer and internet connection). If it is not updating at all, check that your internet connection works and isn't blocked by a firewall.


No, only two hashes. The hash itself isn't typically described as a part of ECDSA though the input must already be hashed (because e.g. a signature of 0 is trivially forged).


I assume you know that mining with personal computer isn't profitable.

On-topic:
There are a variety of algorithms, first you need to find out which algorithm the cryptocurrency you want to mine is based on.
Then find a CPU or GPU mining software that support that algorithm.

One CPU miner that is widely used, and support most of the available algorithms is CPUminer-multi .

You can find the latest about mining on this forum https://bitcointalk.org/index.php?board=160.0


Why this ugly looking formula to calculate 'target' from 'nBits' in block header: target = coefficient * 256**(exponent-3)

TL;DR The formula comes from turning an algorithm into a mathematical formula. nBits encodes the target with the first bytes as the size of the final target, followed by the 3 most significant bytes of that target. This can be converted into that crazy formula.

The formula is the mathematical representation of the actual algorithm that was used for the compression. To understand why the formula is as it is, we need to first take a look at the original code that encodes a 256 bit target as a 4 byte nBits. This is from 0.1.5 in the bitcoin/bitcoin source tree, but is the same in 0.1.0:
unsigned int GetCompact() const
{
    unsigned int nSize = BN_bn2mpi(this, NULL);
    std::vector<unsigned char> vch(nSize);
    nSize -= 4;
    BN_bn2mpi(this, &vch[0]);
    unsigned int nCompact = nSize << 24;
    if (nSize >= 1) nCompact |= (vch[4] << 16);
    if (nSize >= 2) nCompact |= (vch[5] << 8);
    if (nSize >= 3) nCompact |= (vch[6] << 0);
    return nCompact;
}

Now the first thing to look at is this BN_bn2pi function. Early versions of Bitcoin used OpenSSL's Bignum module for these calculations. So we need to look at the OpenSSL's docs for this function. From the docs, we read:

BN_bn2mpi() and BN_mpi2bn() convert BIGNUMs from and to a format that consists of the number's length in bytes represented as a 4-byte big-endian number, and the number itself in big-endian format, where the most significant bit signals a negative number (the representation of numbers with the MSB set is prefixed with null byte).
BN_bn2mpi() stores the representation of a at to, where to must be large enough to hold the result. The size can be determined by calling BN_bn2mpi(a, NULL).

This means that BN_bn2mpi will place into a buffer the Bignum in the format
<4 byte size> | <variable length number>

Calling BN_bn2mpi with NULL as the buffer will return the number of bytes that that buffer will need to be. This is useful to know how many bytes to allocate for the buffer.
So let's go back to the GetCompact function. We see BN_bn2mpi(this, NULL);. This means that nSize is now the size that is needed to encode the Bignum. Because this encoding also includes the size of the number itself, we later see nSize -= 4; which sets nSize to be the size of the actual number itself.
BN_bn2mpi(this, &vch[0]); now encodes the Bignum into vch which was set to the size specified by the first BN_bn2mpi call. It is important to remember that the first 4 bytes are the length of the number, so the actual number itself begins at index 4 (vch[4]).
Finally, the compact number itself is constructed. nSize << 24 is just to set the rightmost byte of nSize to be the leftmost byte of nCompact. Then the function is setting the rest of the compact number. Each byte is just being shifted to it's final position in the 4 byte int and OR'd with nCompact to set it. The if statements are for the case that the target is so low that it is encoded in fewer bytes than the compact size itself.
Looking at this function, we learn that the compact encoding is really just one byte indicating the length of the target, and 3 bytes for the 3 most significant bytes in that target. If you looked at the SetCompact function which takes a compact nBits and converts it into a Bignum, you would see that it is just the inverse of GetCompact, so I won't explain it.
Now the question is, how do we get to the crazy looking formula? How did we go from this code that strictly is just byte manipulation to a mathematical formula?
In your example, based on the above algorithm, we know that the final number is going to be 0x00ffff0000000000000000000000000000000000000000000000000000. We want the first 3 bytes, which we got from the nBits, to be by themselves, so let's divide this number by that:
0x00ffff0000000000000000000000000000000000000000000000000000 / 0x00ffff = 0x010000000000000000000000000000000000000000000000000000

Now 0x010000000000000000000000000000000000000000000000000000 is 26 bytes long, which we can see is because we've removed the first 3 bytes. Now how do we get this number from the nBits? We can take the first byte, representing the length of the full thing, and subtract 3 from it. Then to get that number, because there are 256 possible values in a byte, we do
256**(0x1d-3)

We can expand this further because 256 = 2**8 and some people like things represented as a power of 2. So this can become 2**(8*0x1d-3). Thus
0x010000000000000000000000000000000000000000000000000000 = 2**(8*0x1d-3)

Therefore:
0x00ffff0000000000000000000000000000000000000000000000000000 = 0x010000000000000000000000000000000000000000000000000000 * 0x00ffff = 2**(8*0x1d-3) * 0x00ffff

The final result is 2**(8*0x1d-3) * 0x00ffff. And, of course, this generalizes.

A semi-related question then is why does the Bignum encoding have a leading 0x00 byte? An encoding that represents this maximum target with a little bit more precision would have been 0x1cffffff so we could avoid this extraneous 0x00 byte.
That leading 0x00 byte is all because the Bignum is signed and the target is a positive integer. The most significant bit indicates whether it is negative. If the target had been encoded 0xffff...., then decoding this would mean that the target is negative, which is wrong. So the encoding puts a leading 0x00 so that the number remains positive.


What is the P2P technology/protocol used by Bitcoin to find nodes and distribute messages across them?

Bitcoin has its own custom wire protocol using TCP. Peer discovery is by address rumoring, where connected nodes gossip about other potential available peers. When a node is new and has nobody to gossip with, they make a DNS lookup of specific hostnames which provide a number of known-good peers to make an outgoing connection to. If DNS seeds fail and none of the known peers are good, Bitcoin Core nodes fall back to a set of hardcoded peers as a last resort.

https://bitcoin.org/en/developer-reference#p2p-network

Bitcore, BitcoinJ and python-bitcoinlib all have basic implementations of the wire protocol in JavaScript, Java and Python respectively. It is fairly simple to interact with nodes but misbehavior (such as sending invalid data) will cause the remote peer to ban you.


Is the Bitcoin Transaction ID also the "Hash of things to sign" for the signature generation?

No. The transaction id contains the signatures. But you are making the signatures at the same time, so it can't possibly be the hash that is being signed. How to redeem a basic Tx? describes the actual sighashing algorithm.


Since blockchain is public.. can someone tell how

Yes. Simply paste your bitcoin adress into a block explorer such as http://blockchain.info

For example, this adress has 200$ pending -> https://blockchain.info/address/1Lx4aebbGAUA2ASuYBoiAC2akutzpZQMzb Or, 0.025631 BTC

You can also add a watch-only adress in bitcoin-core / electrum to keep track of balances from certain adresses.


What to look for in Bitcoin-core logfile when something bad happens

I have seen a suggestion to read the log ...

That is a good suggestion.
Normally it wouldn't be needed. The program should explain to the user when it is unable to do something. However if you have been deleting, renaming or moving it's data files, you are undermining it's foundations in a way that the program designers won't have anticipated - in these circumstances, a logfile is a good place to look to try to understand what the problem is.
For any program, not just bitcoin core, you can check for program options to increase the amount of information logged - for example there might be a debug option - often a -d or -debug command-line flag.

... but honestly I'm not sure what I'm looking for.

You are looking for anything that looks like a major error rather than routine activity. Mostly indicated by words like "error", "failed", "unable", "denied" and so on.
You are also looking for messages relating the the action you took just before the unwanted behaviour occurred. In your example, you clicked "Open wallet" so you are looking for messages that contain the word "wallet" or "file" or "open". In Bitcoin core you know the wallet is stored in a file named "wallet.dat" so that is a good thing to look for.
Most likely these messages are near the end of the log file, so that might be a good place to start looking.
If you find lines in the log file that look interesting, also look at nearby lines to get a sense of what the program is trying to do and what might be happening. If you post an extract of the log to a Q&A website like this, include maybe ten or so lines either side of the ones that caught your attention. Don't include too much as no-one wants to read hundreds of lines. Don't post too little.


Trouble CPU Mining with CGMiner and CPUMiner on Ubuntu Server 12.04

It's pointless. With that kind of hardware, it would take you on the order of a month to mine a dollar's worth of Bitcoins, and the electricity used would cost you many times that.


What does "PROOF OF WORK RESULT: false (booooo)" mean when mining?

You're solo mining. So there's nothing useful you can do with a share -- there's nothing for you to share in. Every share you find will be rejected, unless you actually mine a block.


"private" agreement between two c-lightning nodes on channel closure fee

Just use lightning-cli close id the implementation will first try to do a mutual close. Both lightning nodes will use the fee estimator from Bitcoind to suggest fees. If they don't agree there is a communication protocol defined in the BOLTs that they will eventually find a local agreement between themselves. This protocol is described under the section closing negotiation in BOLT 02 c.f.: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed

Obviously both nodes need to be online and peered before you call the close command otherwise the node will do an expensive force close. Also it makes sense to wait until fees in the mempool are low if you can do that.


Where to get the data for Transactions, Graphs as a Bitcoin Exchange

whenever any transaction is made on their website, do they keep this record only to their selves(in their own DB) or is their any central entity of this whole blockchain web where this transaction needs to be registered also?

There is no central entity in a blockchain network. Such a thing would be antithetical to a decentralized cryptocurrency like bitcoin. A user may run a node and participate in the network, without having to trust any of it's peers to provide good information. Instead, the code validates all network interactions, providing cryptographic trust and guarantees.

Exchange services often run as centralized databases, this allows users to initiate many transactions (buying/selling on the exchange), without incurring network transaction fees. The exchange users trade off security (trusting a third party with their coins) for this convenience. However, there are other models that exchanges can use, it is up to your imagination to find a solution that balances trust and convenience in a way that your users will want.

  And where do these websites get data for their live graphs showing the current market value of all the currencies?

Exchanges generally define the market price of cryptocurrencies, this is not data you would pull from a third party. The market price would be discovered by users buying/selling on your exchange, if users push the price too high/low compared to other exchanges, then arbitragers will work to balance it back out.


The issue was that bitcoind was discovering my wrong IPv6 address. (It mistook my link IPv6 address for my public one.) I set --discover=0 and set my IPv4 and IPv6 addresses manually with --externalip.


How many more transactions per second will be possible with SegWit?

Best estimates on effective blocksize with SegWit are 1.6-2.0 MB.

Current transactions/second possible are around 3 tx/s. Given that the effective increase is 1.6 - 2.0x, the transactions/second are also the same multiple giving us somewhere around 5-6 tx/s.

The second question is harder to answer. There's a reason I wrote "effective blocksize" since segwit transaction sizes are different. However a straight blocksize increase on top of segwit indeed would be linear.


What's the difference between an ASIC and an FPGA? Which is better for mining?

I co-founded LargeCoin, Inc., and we really are developing an ASIC for Bitcoin mining. As earlier replies pointed out, the unit cost of ASICs is far lower than FPGAs once you get beyond a few hundred units. The up-front cost of ASIC production varies widely depending on the process you use. On the cheap side, there is so-called "wafer sharing," where your design gets populated on to a wafer with many other designs. Wafer sharing typically uses very old processes that aren't going to deliver the power and density benefits of newer processes. BTW, a "process" refers to a the physical process for making the transistors within the ASIC. Generally a process is referred to by its transistor geometry size - for instance 45nm is a relatively current process.

Next up is "Structured ASICs". A structured ASIC vendor provides an assortment of standard logic components on the bottom layers of the chip. You then add a few metal layers on top of these connecting up the basic components to implement your custom logic. Structured ASICs cost between $100,000 and $500,000 (very approximately) for the first prototypes.

Then there are "standard cell" ASICs, where the chip is designed using standard components that are sort of analogous to software libraries.

And finally, there is "full custom". With a fully custom chip, you are designing everything about the ASIC yourself. The NRE costs for a full custom design is in the millions of dollars typically - particularly if you want to use a modern process.

What process are we using? We're keeping that close to our chest at the moment. However, I can confirm that our detailed modelling at this point indicates we'll be able to mine 250 GHash/s in a single rack of mining units using 5kW of power. When you consider that this represents the computational power of about 400 AMD Radeon 6990 GPUs (which would consume close to 200 kW), you can immediately see the benefit of ASICs for Bitcoin mining.

By the middle of 2012, ASIC mining will be a substantial factor in the Bitcoin economy.


Can I figure out the size of a transaction before its sent?

Yes, this is actually what the raw transaction API is for.

The ordinary send RPCs (sendtoaddress and sendmany) do everything at once:

Construct outputs based on the addresses/amounts you want to send.
Do coin selection to find inputs to satisfy the amounts, determine the fee, and add change if necessary.
Sign the inputs with the keys in your wallet.
Broadcast the transaction to the network.

Since the fee depends on the size of the transaction, which depends on the coin selection, you cannot "intervene" in the middle of these RPCs.

The raw transaction API lets you do all these steps independently:

Constructing outputs based on addresses/amount using createrawtransaction.
Do coin selection to find inputs, determine the fee, and add change using fundrawtransaction.
Sign the inputs using signrawtransaction.
Broadcast the transaction using sendrawtransaction.

If you need to know the actual fee before broadcasting, you can use createrawtransaction + fundrawtransaction + signrawtransaction to construct a fully valid transaction without broadcasting. You can then inspect it, and decide to broadcast it using sendrawtransaction or not.


Compiling Maxcoin and its clone cryptos throw an error

So I finally decided to give up trying to use qt 4.8.5 and helixcoin and galleoncoin github sources. And used qt 5.2.0 with slothcoin source from github. Which worked fine. And qt wallet started without a problem. Though I still dont understand why was qt 4.8.5 not including the msrvct.dll file. maybe that these libs were never included in qt 4.8.5? Seems to be compile fine on windows 8.1 and ubuntu 12.04 :)


Is there a way for merchants to insist on a tx fee to increase likelihood of the tx (eventually) being accepted into the blockchain?

In short, no.  You can tell the customer whatever you want on your webpage, at your point of sale, or in the memo field of a BIP70 invoice---but once the transaction has been sent to the network, there's no way for the customer to take it back.  (Except for double spending, but that's discouraged.)

In the long-term, miners will likely change their transaction-selection process to allow for child-pays-for-parent fee calculation.  For example, imagine merchant-created unconfirmed transaction B spends an output from customer-created unconfirmed transaction A.  Currently, most miners use a naïve formula for selecting whether to include those transactions in their block attempts:

If transaction A pays a high enough fee per kilobyte, include it in the block.
If transaction A is included and transaction B pays a high enough fee per kilobyte, include transaction B as well.  (Note, consensus rules don't allow including child transaction B before its parent transaction A.)

In child-pays-for-parent, the miner will do the calculations above the same but also do a third calculation:

If transaction A's fee plus transaction B's fee is high enough per kilobyte of the combined size of transaction A plus transaction B, include both transactions in the block.

This allows merchants to effectively add a fee to any low-value transactions, helping to encourage miners to confirm those transactions quickly.  This method does have some overhead, so having the customer pay an appropriate fee would be ideal, but it can help prevent transactions from getting stuck.


Is it worthy to use "bitcoin usb block erupter"

A typical USB block erupter will get 333MH/s under realistic conditions. Today, a share is worth about 1/156 of a penny and 333MH/s will get you a share every 13 seconds. That comes out to 43 cents per day per erupter, not counting the cost of electricity. Difficulty is going up, and thus profitability going down, around 25% per month. So you can figure maybe $11 your first month, $8 your next, $6 the next, then $5, and so on. You might get about $50 before it becomes more trouble than it's worth.


Lightning Network wallet applications for different operating systems?

Android Lightning Network wallets

https://github.com/ACINQ/eclair-mobile

https://lightning-wallet.com


The JSON-RPC interface is a way for other programs to interact with Bitcoin-Qt or bitcoind while it's running. It's useful for doing things like mining or building a web site that needs to talk to the Bitcoin network directly. Most users don't need to worry about it or set it up.