Do any hardware wallets / hardware platforms that rely on or allow open source firmware?

See here the latest list of 27 hardware wallets, many use open source software in the meantime - flagged with a (O). The other ones are flagged with a (N).
For security reasons it is of course not sufficient to consider the software alone, also hardware can contain backdoors.

(O) Archos Safe-T (Mini)
(O) BC Vault
(O) Bitbox
(O) Bitfi
(O) BitLox Hardware Wallet
(?) Card Wallet
(O) Cobo Vault Wallet
(O) ColdCard
(N) CoolWallet S --> plans to (O) it in future
(N) D’CENT Hardware Wallet
(N) Ellipal
(N) Ellipal Titan
(O) Keepkey
(N) Keevo Wallet
(O) KeyCard
(N) Ledger Blue
(N) Ledger Nano S
(N) Ledger Nano X
(N?) MIRKey by ellipticsecure
(O) Opendime
(N?) SafePal S1
(O) Secalot
(N) SecuX V20
(partly O) Temexe X Wallet --> backup algorithm is open source
(O) Trezor One Wallet
(O) Trezor T
(N?) XZEN Wallet


Is it likely that side-chain support will be added to Bitcoin?

Yes, it is very likely that Bitcoin will support side chains within the next few years.  (By my guess, not 2015 but maybe 2016.)  Side chain support does not require a hard fork---it only requires a soft fork.  As the sidechains paper explains (page 10, final paragraph):

  To use Bitcoin as the parent chain, an extension to script which can recognise and validate such
  SPV proofs would be required. At the very least, such proofs would need to be made compact
  enough to fit in a Bitcoin transaction. However, this is just a soft-forking change, without effect on
  transactions which do not use the new features.

Note that Bitcoin doesn't need a special counter to keep track of value sent to child chains---it already keeps track of every spendable balance.  Sending bitcoins to a side chain will be essentially the same as sending money to any other bitcoin address---except that you'll need a special tool to create the transaction for you.  Receiving bitcoins back from the side chain will also require the special tool, but that tool will just create a transaction that spends one or more of the transactions previously sent to the side chain.  (Note that the tool will need to operate on both the side chain and the Bitcoin block chain to maintain consistency.)

As an aside, hard forks are only as difficult as it is to convince people to upgrade.  The most recent hard fork, the August 2013 fork mentioned in BIP50, was relatively easy because it was a fix for an acknowledged major bug.  On the other hand, Gavin Andresen will likely soon be proposing a hard fork to increase block size that may be quite difficulty because it's a major change to how Bitcoin has worked since 2010.

Pegged side chains falls somewhere in between those two extremes (and it is only a soft fork), so I guess it will "only" take about 3 months of discussion and testing once a patch/BIP is proposed and about 6 months to fully rollout the soft fork, similar to the rollout of BIP34.


How to count the provably unspendable UTXO in the blockchain?

When you say "transactions", I assume you mean "transaction output".
It is literally not possible to have a transaction output that is larger than the transaction size limit. Otherwise the transaction containing that output would not be in the blockchain.
Rather I think what you are looking for is that the output script is larger than the maximum script size. Such scripts are provably unspendable and can be excluded from the UTXO set.
Bitcoin Core has a function to determine whether outputs are unspendable. It is not an exhaustive list and is just the two that you mention: Scripts beginning with OP_RETURN, and scripts larger than the max script size.
However there are other scripts that are provably unspendable, just that they require a little more work to prove. For example scripts that use invalid or disabled opcodes are provably unspendable. The script interpreter will fail if any such opcode is found in the script when it is verifying the spend.
But even that has a catch. Unknown opcodes that are not executed (e.g. in an unexecuted IF branch), the script can still pass validation. However if the script contains any of the disabled opcodes anywhere (there are a few exceptions to this as some "disabled" opcodes were actually just outright removed), it is invalid.
There are also potentially scripts that require something larger than the maximum stack item size to be pushed to the stack. Or something that manipulates a stack item so that it becomes a negative locktime when used with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY.
Then there are output scripts that are programmed invalidly such as having just an OP_ELSE or OP_ENDIF with no OP_IF/OP_NOTIF coming before it.
All of these things are hard to determine and really require inspecting the individual scripts. They also require having a consensus conforming script interpreter, which itself is hard to do because the exact semantics of scripts are actually unclear.


Are "1" , "3" and "Bech" Addresses (BTC) forward and backward compatible?

All current addresses are cross compatible.

At a technical level, the chain has no concept of an address, only of locking scripts, which are fragments of a bitcoin script program. You send coins by specifying the locking script, and spend them by providing the unlocking script (also called the script sig), which completes the program by providing the correct inputs to produce a valid output (TRUE, for a valid transaction).

Since there is no concept of an address here, they are all compatible with each other.

Addresses are a secondary encoding performed on standardized scripts to aid human readability, and prevent typographical errors via checksums and error detecting mechanisms.


How do i get info from Bitcoin QT 0.7 to Bitcoin QT 0.11?

A blkindex.dat error means that the block index has been corrupted or can't be opened. However, the block index is not part of the wallet, and can be deleted without removing the funds in your wallet.

With that in mind, try this:

Open %APPDATA% in file explorer. Do this by pressing Windows + R, then typing %APPDATA%.
Open Roaming\Bitcoin.
Make a new folder in there called 'old block files,' or something similar.
Move every file in that folder except wallet.dat into the old block files folder.
Optionally, delete the 'old block files' folder.
Start Bitcoin 0.11, and your computer will redownload the block chain. This will take a few hours.


What are the weakest cryptographic guarantees in Bitcoin?

This doesn't directly answer your question, but in ECDSA, if the private key is close to one of the 768 rendezvous points on the secp256k1 curve, it is considered a weak private key and can be compromised. See this BitcoinTalk thread. In practice, this isn't a huge threat as long as you use a good source of randomness since the space around those rendezvous points is a miniscule fraction of the total keyspace.


How is a transaction verified in a micropayment channel?

In the process of opening a micropayment channel, the two parties put funds into a lock-box of sorts that requires both parties to sign off any any withdrawals from that lockbox. In the blockchain, this is essentially putting some funds into a 2-of-2 multisig output, where the 2 keys are Alice and Bob's keys. If only Bob is going to be transferring money to Alice or vice versa (unidirectional), then only one person need put funds into the 2-of-2 lock box.

Then, when it comes time for Bob to pay Alice, Bob gives Alice a transaction that spends the contents of the lock box, giving Alice some amount of the lock box funds and using a change output that puts the change back into the lockbox. Since withdrawing from the lock box requires both Alice and Bob to sign off, Alice can confirm when Bob has signed off to give her funds.

Notice that it has to be this way, requiring both Alice and Bob to transfer funds through the channel, because if it just required the sender of the funds, you run into the exact problem you mentioned: the sender could be trying to double spend those funds and you wouldn't know.


I would estimate that there are 30 public servers and 11 validators as I'm typing this answer.

I estimated the number of public servers by connecting to a number of servers and collecting the node keys of every server connected to them. While node keys are free to change, each server has a unique node key while it is connected. This is used to drop duplicate connections. So this should count each public server once.

I estimated the number of validators by collecting the validator public keys of every validation I saw published over a five minute period. I counted the number of unique validation keys.

I can't see any reason these counts could be too high, but they certainly could be missing some.


What does bitcoin actually do with these problems?

Contrary to popular belief, mining is not actually solving any problems. There are no math problems that miners are working on to solve. Rather what miners are doing are just hashing data and then seeing if the resulting hash is less than a given target which everyone can calculate independently with data from the blockchain. The work that they are doing is only for securing the Bitcoin blockchain; it is not useful for anything else. So they aren't solving puzzles or problems, they are just doing work to make the Bitcoin blockchain secure.


The Bitcoin reward schedule follows a predetermined pattern, see Controlled supply from the Bitcoin wiki.

The next reward drop will happen at block number 420000. The current block number at the time of writing this answer is 318662. There are about 101338 blocks remaining. At approximately 10 minutes per block, there are approximately 1008 blocks per week, and 101338 divided by 1008 is about 100.5. So you can expect the next reward drop approximately 100 weeks from now, or around August 2016.

The http://bitcoinclock.com site does this calculation for you and provides an estimate right at the top. At the time of writing this answer, it says:

  Reward-Drop ETA: 2016-08-05 12:47:44 UTC (100 weeks, 3 days, 17 hours, 40 minutes)


How do I move my wallet from Windows 7 to a new Windows 10 machine?

First - you didn't specify if you use Bitcoin Core or any other program for maintaining your wallet, so the answer below presumes you used Bitcoin Core.

The short version: it stores all of its data in %AppData%\Bitcoin
This folder usually translates to C:\users\\AppData\Bitcoin

Underneath that folder you will find there the 'wallet.dat' file.
This is the file that has all of your addresses (including private keys). This is the file you'll need to copy.
You will find in that folder also a subfolder 'blocs' which is your local copy of the entire block chain.

On both Win7 and Win10 those files reside under the same folder - %AppData%\Bitcoin.

So - simple copy instructions:

Install Bitcoin on the new (win10) machine (and don't start it yet)
Stop Bitcoin on the old one
Copy %AppData%\Bitcoin\wallet.dat from old to the new one
You may also want to copy the entire %AppData%\Bitcoin\ folder with the rest of the files and block chain, or you can download it again (it's "only" 20+ gigabytes)
Once you're done with the copying you can start Bitcoin Core on the new computer.

That's all.

See https://en.bitcoin.it/wiki/Data_directory for more details.


Why does Bitcoin Core not support showing the prices in USD or other fiat currencies?

Why do they not want to add this feature?

There is no "they". You can create issues or open pull requests to see feedback about a feature request from others.
Few reasons I would not want such feature in a bitcoin wallet:

Bitcoin Core wallet is an open source bitcoin wallet which is used by people from different countries with their fiat currencies. Lot of currencies and API for exchanges will be used to add such feature.

Bitcoin wallet doesn't need amounts mentioned in other currencies when it has its own currency which is BTC. I do not want to see amounts mentioned in EUR when I login to my bank account in India. Amounts mentioned in INR works better.


Bitcoin Speed: 7 Transactions Per Second?

I read somewhere that Bitcoin can only handle 7 transactions per second.

That's roughly correct - only about 7 transactions per second can be confirmed using legacy transactions.  With the recent adoption of segregated witness, it could be closer to 30 transactions per second.

  I find it hard to believe that so many people would buy into a system that's so inefficient / unscalable.

Some people might have confidence that a better solution will eventually be found.  The protocol can be changed with community consensus.  Others might find that it is good enough for what they need in the short term (a particular transaction, day trading, etc) and not care what happens in the long term.

  Also, if my assumption is correct, suppose there are (on avg) 700 transactions per second during a given 10 min period (i.e, 70 times the max output rate) does this mean we will need to wait 70 * 10 min for all those transactions to be confirmed? If yes, why can't some evil actor overwhelm (i.e, postpone) the system by submitting thousands of tiny transactions to the network?

Transactions are not first-come-first-served.  Miners can decide which transactions will be confirmed, and usually this is done by prioritizing them by  highest fee.  So if the attacker doesn't include competitive fees in those transactions, they will simply never get confirmed and there is no issue.  If he does, then the attack is potentially quite expensive for him.  And even in that case, honest users who really need their transactions confirmed can simply offer an even higher fee.


Where can i buy zcash coins, named as ZEC?

Try trading on exchanges for ZEC. Some of the exchanges are bitmex, poloniex, kraken, etc. Most exchanges will allow you to buy zcash in exchange for bitcoins.


Bitcoin Core probably will never have a "1.0". 1.0 is a socially significant number which indicates some kind of finality or completeness (at least initially). This itself is holding back developers from declaring that there may even be a 1.0 or creating some timeline for a 1.0. Bitcoin Core is being continuously developed and there is no point at which many developers foresee it becoming this kind of "final" or "complete" that 1.0 implies.
There is no timeline nor a roadmap for 1.0. There isn't consensus that there should even be a 1.0. There isn't consensus on what features would be required for a 1.0. It is highly unlikely that there will ever be a 1.0. What is more likely to happen is that versioning stays as it is. Maybe in the future the leading 0 will be dropped, or perhaps some other continuous versioning scheme will be used (such as a date based one). But because of the social implications of 1.0, that will probably never happen.
A big part of this has to do with the release cycle of Bitcoin Core. Releases are done in a time based fashion - every 6 or so months, a new release is made. The primary version number just keeps getting bumped for every release. If Bitcoin had started with a 1.0 instead of a 0.1, we'd probably see the same pattern happening today, it would just be 19.1 instead of 0.19.1. But going to a 1.0 is changing the versioning scheme, and there is simply no reason to do that with the given versioning scheme. It would imply some kind of feature change or a major shift in development direction.

From 22.0 onwards, the leading 0 has been dropped from the version number. This was implemented in PR 20223. The last version to contain the leading 0 is 0.21.


Prevent rounding errors when displaying bitcoin values in javascript

Good idea on storing it in Satoshis. With anything involving money, you want to avoid floats due to rounding errors. The best way of doing this would be to parse the value in Satoshis as a string, then simply put a decimal place 8 digits from the end to get the value in Satoshis.

function convertToBTC(satoshis){
    var satoshi_string = satoshis.toString();
    var len_satoshi   = satoshi_string.length;
    if (len_satoshi < 9){
        concat_string = concat_zeroes(9 - len_satoshi, satoshi_string);
     }
    var btc_len = concat_string.length;
    var decimal_place = btc_len-8;
    var bitcoin_string = concat_string.slice(0,decimal_place).concat('.').concat(concat_string.slice(decimal_place, btc_len));
    return bitcoin_string;
}

function concat_zeroes(num_zeroes, string1){
    while(num_zeroes){
         string1 = '0'.concat(string1);
         num_zeroes -= 1;
    }
    return string1;
}


Solve problems using bitcoin smart contracts

What will be the best way or resources to refer if someone has an idea and want to implement it using bitcoin smart contracts?

If smart contracts involve the use of external data (oracles) then Discreet Log Contracts are the best possible way.

How would I approach solving this problem using bitcoin?

I have mentioned few points in this doc, it won't be easy creating an oracle that decides if someone is dead or alive, create incentives around it, use of funds, exception handling etc. however nothing wrong in trying: https://docs.google.com/document/d/1baOWfya2mqd3ZAoDS4a2VQlb3-q4JCILXRN-oe4_zOk/edit

What are best resources to learn more about discreet log contracts, it's examples?

DLC channel in Lightning Dev Kit slack :https://lightningdevkit.slack.com/
Examples:
P2P Derivatives: https://github.com/p2pderivatives/p2pderivatives-client
https://medium.com/crypto-garage/step-by-step-guide-p2p-derivatives-application-c0454606428e
Benthecarman is working on a project which can be used to experiment with DLC (scala):
https://github.com/benthecarman/krystal-bull

Nicolas Dorier is also working on NDLC and I tried a creating a GUI for NDLC-CLI using C#:


Is there a good exchange where I can withdraw to PayPal?

Short answer: No.

Long answer: PayPal does not allow Bitcoin exchange accounts. Bitcoin exchanges pop up like mushrooms these days so a new one might fly under PayPal's radar and get an account going for a while. But it will eventually get shut down.

So trustworthy exchanges won't try to use PayPal, as they know their accounts will be seized. And you shouldn't trust those that are using PayPal because they're operating with high risk. Knowing the high risk.

PayPal's CEO talked about Bitcoin as a funding option on PayPal in an interview during the last couple of months.

Until that happens the answers above are unlikely to change.


BOLT #3: Shouldn't timeout be included in the script of "Offered HTLC Outputs" for the local node?

Pierre answered my question on the lightning-dev list and there is a pull request in order to make it more explicit. So the answer is that although the timeout is not addressed in the script, it is enforced in the HTLC-timeout transaction with an absolute timelock in the nLocktime. When the local node tries to spend the HTLC output, it has to explicitly set the nLocktime to cltv_expiry which prevents it from broadcasting the second-stage HTLC-timeout transaction until that time has reached.


How long does it usually take to mine a bitcoin block?

For solo mining with a single GTX 680, which will produce 120 Mhashes/s, you would expect to find one block approximately every 98 years.

At the current difficulty, solo mining is inadvisable under practically all circumstances.  Pooled mining should be done instead.

Furthermore, mining utilizing graphics cards is rapidly losing viability with the release of FPGA and ASIC-based mining hardware, which operates at far greater efficiency.  Unless you have exceptionally cheap electricity or have a use for the heat output from the graphics card(s) (e.g. heating your house for winter), graphics card mining is unlikely to be profitable for you.

Additionally, mining with NVIDIA graphics cards has pretty much never been worthwhile, as they are far slower and less efficient than comparable ATI/AMD hardware, conflating the above issues with graphics card mining.


How is wallet balance from unspent transactions in cryptography terms?

Is a bitcoin wallets balance calculated on the client computer app? eg. Leger Live

yes.

How is bitcoin wallet balance calculated cryptographically?

There's no cryptography involved, certainly no encryption.
You add the credits and subtract the debits.

Does Ledger Live app check/compare each transaction+hash & transaction+signature hash like mempool nodes do?

All nodes verify the data they receive, so far as they are able to. This involves computing hashes and verifying digital signatures. see Wikipedia article and Mastering Bitcoin, Chapter 4

Or does it only look at the unspent output addresses and check if they are children of wallet public key?

Yes.

If so how does it do this in cryptography terms?

Since wallets derive these keys and addresses, they just keep a list of them.
The original derivation involves hashes. The hashing algorithms come from the world of cryptography but are not encryption.
The method for deriving many addresses from a single seed is described in BIP32


Why does the default miner implementation use pay-to-pubkey?

Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.

Is this space savings why Nakamoto chose to use P2PK for mining and interactive payments even when he had P2PKH available, or did he have some other reason for using different transaction types?  I think only he knows.

In a situation where you don't need the shorter P2PKH addresses, such as mining, interactive payments, or paying to your own pubkey for change, using a P2PK may be the better option, although there is a security advantage to P2PKH if you don't reuse addresses and if ECDSA someday gets broken in a certain way that makes attacks possible but slow to execute.

Type   Output                Input             Total Bytes
       ScriptPubKey          ScriptSig

       push ....... 1        push  ... 1
       <key> ...... 33       <sig> ... ~72
P2PK   checksig ... 1
       --------------        -------------
       Total ...... 35       Total ... ~73     ~108

       dup ........ 1        push .... 1
       hash160 .... 1        <sig> ... ~72
       push ....... 1        push .... 1
P2PKH  <hash> ..... 20       <key> ... 33
       equal ...... 1
       checksig ... 1
       --------------        --------------
       Total ...... 25       Total ... ~107   ~132

The numbers above assume that you're using a compressed public key, which are widely used today but were not implemented until Bitcoin Core 0.6.0.  If you want to consider the older "uncompressed" public keys, add 32 bytes to the <key> byte sizes.  Also, we ignore all constant factors in creating an output or input and just consider the number of bytes in the script.

I'm not aware of any compatibility issues---plenty of miners and mining pools use their own software to pay to P2PKH addresses, as you can see from the coinbases in recent blocks.


Mastering Bitcoin: Advanced Scripting Question

They 'reset' the clock by moving the funds to a new output before the period ends.


Can a wallet allow you to receive Bitcoins from the same wallet you send them from?

Some wallets do allow you to receive coins to the same addr they are sent from. But generally this is not a good idea; your transactions could be more easily traced this way.


Create your own coin, do a Ninja launch, know how to point appropriate pre-booked hash at low rates, do exceptional marketing, make lot's of false promises about a road map, ensure all the pools that mine altcoins pick up for the launch (pre-negotiated). Have a roadmap for development filled with false promises and tons of nonsense, a gimick can help.

Launch your nodes; launch, mine the majority stake of the supply, then manipulate the price using multiple accounts on the exchanges using automated trading software, creating tons of volume thus drawing attention.

Cycle this endlessly, up and down, and basically milk every newbie who enters the game on how it works... You only learn the hard way.


Have bitcoin developers applied the solution for selfish miner attack?

Note that there is a new and better paper about this topic by Aviv Zohar et al. - http://arxiv.org/pdf/1507.06183v1.pdf.

None of the solutions suggested have been implemented yet. The attack is significant enough that some solution will need to be found, but that's up to researchers, not developers.


How to list all the HD address in Electrum?

Is not feasible to show all possible addresses, there are just too many.
However you can change the gap limit.

By default, Electrum shows the first 20 private keys.

You can change that by going to console tab (view menu > show console) and typing in this:

wallet.change_gap_limit(200)
wallet.synchronize()

The above will increase the number of unused addresses past the index of the last used address to 200 i.e. this becomes the new Electrum lookahead window.

If you want to generate change addresses instead you can do the following:

for thing in range(1,200): wallet.create_new_address(True)


You can find an extensive list on page Trade at Bitcoin Wiki.

A short list of some auction sites that use Bitcoins:

Bid Bitcoins
Bidding Pond
Bitmit

If you want to sell digital files per download, go here: http://bitcoinservice.co.uk/ .

And as with anything, you can just post on an online classified ad websites, such as craigslist (thanks Thilo for the suggestion).


Can SPV clients offer "proof of absence" of a transaction?

There is no known way to do this with the current consensus rules nor does it seem likely except via computationally expensive general ZKP.

The normal way to make compact proofs of non-membership is to have a hash tree which is ordered by the key you're looking to prove non-membership on.  The proof is just the two neighbors that are greater and lesser than the key in question.

To show non-membership in a block this with a general ZKP (like bulletproofs) you would have to write an arithmetic circuit that computes the hash root of a block, and also scans over transactions looking for the thing-of-interest.  If done using a bulletproof the proofs would be log in the size of the circuit, and take time to prove and verify linear in size... so they'd be somewhat slow but bandwidth efficient.


What is the benefit of opening port 8333 to a client?

If you don't want to, you don't have to open ports at all. You'll still have a full node, it will just have fewer connections. Full nodes usually make 8 outgoing connections and can have many more incoming if you have the port open (for a total of 125 by default). Incoming connections can also be SPV (phone) wallets, or other full nodes.

So the benefit is that you're helping out the network a little bit more providing connection opportunities and bandwidth to more other full and non-full nodes. There's not really a shortage at the moment though.

Typically only the first time when you run the software it might do a DNS lookup on the domains you mention. Each name represents dozens of IP addresses of random other full nodes (not just nodes run by those people). Once your node has a connection to a few peers, it will learn new IP addresses from those, maintaining its own list of IP addresses which is stored when you close the software shuts down.


Is there an updated accurate list of retailers who accept Bitcoin from Canadians?

You're asking 2 questions here..

1) list of retailers/hotels: try this site https://spendbitcoins.ca/

2) bitcoin is borderless. if they accept it, they accept it. now that's not to say a geo-located website might accept btc on their american (.com) site but not the british version (.co.uk), as overstock do. but that's a business decision, not a property of crypto currencies. think of it this way: if a business accepts it, they have a wallet address you can send money to, as long as you have a wallet too. doesn't matter where in the world you are. kind of like email.


The final hash verification is the same one done in mining. The difference it's that is done just once, while in mining it's done lots of times, until the miner finds a hash on the target difficult.

It's similar to checking a database of pictures of stores to tell if there's one that's a pizzeria. You look to hundreds, even thousands of random pictures, your eyes and brain working on what you see to tell what the picture is, until you find a pizzeria. Then you post it online and people see it and they say, 'yeah, it's a pizzeria'. They only had to look at a single picture to validate it.


Are there statistics on how Bitcoin holdings are spread among addresses?

I don't know if any of this data is of any use or significance, but...

I calculated the Gini coefficient at the end of each month of Bitcoin's history.  I did it in two different ways:

The vast majority of Bitcoin addresses that have ever been used are now empty.  They don't represent the "have nots", they're just addresses that have been used and discarded, and so shouldn't be included in the calculation.  Similarly there will be lots of addresses which are holding change from transactions.  I arbitrarily decided to throw away all addresses with a balance of less than 1 BTC for this first calculation.
Then I calculated the Gini coefficient for just the 100 richest accounts at the end of each month.

The results are shown below, with the columns in order:

the date.  "Jan 09" means "the end of Jan 09"
the total number of addresses in existence at that date, including empty ones
the number of addresses with 1 BTC or more in them
the amount in the richest account
the amount in the 100th richest account (notice how this stayed at 50.00 for over a year)
the Gini coefficient of the >= 1BTC addresses
the Gini coefficient of the top 100 addresses

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 09       2,569     2,439     2775.00 -   50.00   0.04571   0.50862
Feb 09       5,975     5,642     9075.00 -   50.00   0.05064   0.71354
Mar 09       9,444     8,864    16675.33 -   50.00   0.05794   0.82048
Apr 09      12,893    12,120    21175.33 -   50.00   0.05715   0.85527
May 09      16,288    15,380    26675.33 -   50.00   0.05306   0.87075
Jun 09      18,528    17,534    30675.33 -   50.00   0.05118   0.87980
Jul 09      20,456    19,338    36675.33 -   50.00   0.05248   0.89165
Aug 09      22,021    20,741    44473.86 -   50.00   0.05617   0.90351
Sep 09      24,180    22,639    53974.86 -   50.00   0.06188   0.91664
Oct 09      26,311    24,366    61424.62 -   50.00   0.07208   0.92725
Nov 09      28,533    26,403    61424.62 -   50.00   0.07279   0.93164
Dec 09      32,611    29,818    61424.62 -   50.00   0.08352   0.92241

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 10      37,647    34,333    72374.36 -   50.00   0.08571   0.92339
Feb 10      43,329    37,262    72374.36 -   50.00   0.13683   0.88570
Mar 10      48,615    40,316    72374.36 -   50.10   0.16674   0.82492
Apr 10      57,806    42,661    72374.36 -  500.00   0.21059   0.71037
May 10      63,368    44,583    72374.36 -  630.00   0.24448   0.65747
Jun 10      69,540    46,963    72374.36 -  750.00   0.26638   0.62843
Jul 10      94,992    51,628    72374.36 - 1757.14   0.32583   0.56689
Aug 10     107,172    53,578    72374.36 - 2100.02   0.35365   0.52483
Sep 10     120,562    53,492    72374.36 - 3000.00   0.39915   0.46956
Oct 10     135,952    54,637    85000.00 - 3333.33   0.42841   0.46050
Nov 10     155,639    55,756    90000.00 - 4150.00   0.45464   0.43790
Dec 10     176,326    57,247    90000.00 - 5000.00   0.47592   0.38625

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 11     210,243    58,073   250000.00 - 5350.00   0.49987   0.47440
Feb 11     267,542    59,699   250000.00 - 5650.51   0.52439   0.47584
Mar 11     353,093    61,984   250000.01 - 5613.86   0.54646   0.45504
Apr 11     443,112    64,254   200000.00 - 6002.81   0.57161   0.46808
May 11     631,480    70,883   297000.00 - 6309.40   0.62830   0.49247
Jun 11   1,061,590    90,159   424242.42 - 6308.24   0.70803   0.52602
Jul 11   1,548,806   101,895   384587.42 - 6450.00   0.73473   0.50905
Aug 11   1,930,979   105,572   104895.01 - 7495.92   0.74448   0.41533
Sep 11   2,205,926   106,973   105000.00 - 6926.85   0.74847   0.45014
Oct 11   2,411,298   110,463   105000.00 - 7345.73   0.75422   0.44981
Nov 11   2,601,999   111,386   455501.30 - 6926.85   0.76065   0.51328
Dec 11   2,768,500   118,263   105555.00 - 6705.00   0.76137   0.41685

-date-   addresses    >1 BTC   1st - 100th richest   Gini >1   Gini100
Jan 12   2,956,869   123,003   105555.00 - 7000.00   0.76883   0.42408


Physical objects on the blockchain as data?

I can't tell you about any specific diamond-tracking company, but I can address the complications with tracking any physical good on a blockchain.

In order to track a physical object on a blockchain, that physical object needs to be able to reduce to a small piece of data, such as a hash digest.  With digital goods, this is easily accomplished with a cryptographic hash function, but physical objects present some difficulties.  You'd need a method of reliably and repeatably coming up with the same reduced value from the same physical object.  If a diamond were "hashed" in London today by one jeweler, you would need to be able to expect that if it were hashed again by a different jeweler in New York in 20 years, the result would be the same.  Not just close, but exactly the same.  This is probably where the physical "passport" you speak of fits in, but in that case, you are relying on the chain of custody of the passport.  The blockchain would be tracking the passport, not the diamond.  How the passport is identified to belong to a certain diamond is something you'd have to ask a jeweler.

You would also need to trust whatever layer is built on top of the blockchain, and that they are following the rules they claim to be following.  In this case, it would be whomever issues these passports.  For example, what would happen if the passport-issuing authority issues two passports for the same diamond?  The passports could be traded separately on the blockchain, but there is still only a single physical good...but with two blockchain-legitimate claims to it.  Also, who is in charge of enforcing the ownership of the physical good?  If I have the diamond, but you have the blockchain token, who is going to physically take the diamond from me and give it to you?

It might be wise to pose these questions to whichever company is claiming to be able to track ownership of a physical good by using a blockchain.


Why BIP32 derive address does not match with BIP39?

It doesn't. You read it wrong, first snippet shows you account key for m/44'/0'/0'/0 derivation path, second snippet for m/44. As the derivation paths are different - obviously the accounts' keys are different too.


Reason behind hashing the nonce in prevBlockHash?

Yes, you're correct. Without the nonce, we could still generate valid blocks.
However, to get a different hash we need to change the input for the hash. The input for the hash is the block header.

If there were no nonce, we would have to change something else about the block header for each try. That would only leave the timestamp or the Merkle root.  Other header items are fixed.
The timestamp is icky, because we would like it to show the actual time. So, we'd have to change the Merkle root.

The Merkle root calculated by hashing all transactions in the Merkle tree where they are listed. If we change e.g. the Coinbase or the order of the transactions in the tree, we could also gain another different combination to try. But to do so, we'd have to recalculate the Merkle root.

Rather, we put a nonce in the header directly that allows us to use the same block candidate for a number of different hashing attempts.

Hence, the nonce is used to introduce randomness into the blockheader. That's why it

a) has to be changed, and
 b) has to be in the blockheader. ;)


Is it possible to send a message to a bitcoin address? how?

Not in any way that is intended by the protocol.

What do you mean by "ultimately the entity involved in a hypothetical trade"? It's just a hash of a public key, the corresponding private key to which you hold.

What is preventing you from having a contact form or e-mail address in the online store?


Bitcoin Wallet: Will 2 payments within 10 minutes cause double spending

If you have enough Bitcoin in your balance it will be all good. Double-spend transactions should only really be made maliciously by reusing the same inputs. If you are using a known wallet you should not have any issues.


Is there a calculation for exchange rate stability?

This site can help you calculate the beta of Bitcoin:

https://btcvol.info/

"What definition of volatility does btcvol.info use?

The standard deviation of daily returns for the preceding 30- and 60-day windows. These are measures of historical volatility based on past Bitcoin prices. When the Bitcoin options market matures, it will be possible to calculate Bitcoin's implied volatility, which is in many ways a better measure."

https://en.wikipedia.org/wiki/Beta_(finance)

In finance, the beta (β or beta coefficient) of an investment indicates whether the investment is more or less volatile than the market. In general, a beta less than 1 indicates that the investment is less volatile than the market, while a beta more than 1 indicates that the investment is more volatile than the market. Volatility is measured as the fluctuation of the price around the mean: the standard deviation.


When exactly do the transactions get validated?

The question at this step is: does the wallet app perform any kind of transaction validation that requires to check the whole history of the blockchain at this level ?

It depends on the wallet.

In general, a wallet will likely do some validation as a sanity check to ensure that the transaction they create is valid and will be accepted by nodes on the network. They will usually check that the signatures are valid and that the transaction is valid assuming that the previous transactions it spends from are also valid.

Whether those previous transactions are valid are a different story. There are different validation and security models that are employed. But generally, a wallet will only store and recognize a transaction as its when it believes it to be valid. It will then rely on the assumption that it is valid (whether it validated it or has some other means to believe it is valid) so that it does not need to re-validate the transaction later.

  2) The broadcasted transaction is now sent to many nodes on the network, and these nodes forward/ "propagate" the transactions to other nodes till all the nodes have this transaction in their "pool of unconfirmed transactions" ?

That is correct. But at this stage, nodes validate the transaction using the full transaction history before they relay the transaction further onto other peers. Note that they don't re-validate previous transactions nor do they linearly search through the blockchain. Rather they have databases and  indexes which make transaction validation extremely fast.

Additionally, not all nodes need to have the transaction or to have seen the transaction. There is also no way to know whether all nodes have seen and validated a particular transaction.

  The question here is: do the nodes perform another validation at all the transactions sent with the block header to verify they are real transactions not fake ones created by the miner who solved the block ?

Naively (and previously), yes. A simple implementation would simply re-validate every single transaction received in a block.

A faster implementation (and what Bitcoin Core does now), is to cache whether a particular transaction has been validated before and whether it was valid. So when it goes through a block, instead of re-validating all the transactions that the node has seen before, it just calls up the validation result previously. This can be easily done by restricting the mempool (pool of unconfirmed transactions) to transactions that would be valid if they are included in he next block. So if a transaction that is received in a block is found in the mempool, then it is known to be valid and does not need to be re-validated.

  I know how merkle trees hash multiple transactions and that any modification to a transaction's hash will change the merkle root's value, but my question here is how is that helpful ? wouldn't the miner who already faked up any of the transactions have the right merkle root for all the transactions in the block since he is the one who added them in the first place ? My point is how does merkle root help ? what value does it add ? what kind of attack does it prevent ?

The merkle root has nothing to do with transaction validity.

The merkle serves two purposes: to ensure that all transactions are included in the block hash, and to prove that a particular transaction was in a block without needing the block itself.

Since the merkle root is part of the block header, and since it is the hash of all transactions in a block, it serves to commit all of those transactions to the block header and to the Proof of Work. It just ensures that the block hash covers the transactions as well.

The merkle tree used to produce the merkle root also means that anyone with a full block can produce a simple proof that a transaction was included in a particular block. This is useful for SPV wallets. It does not prove that a transaction is valid and has no effect on whether a transaction is valid. A miner could include an invalid transaction and it would be part of the merkle tree. This doesn't make that transaction valid, nor does it make the block valid.

  The last question is the consensus, from its definition it is that all nodes agree that they are at the same level with the new block. I know the PoW, but how all the nodes check and communicate together to acknowledge that all of them got the same block ?

They don't; there is no need to. Consensus is reached because nodes are connected to each other and broadcast blocks to each other. Because every node is programmed to follow the blockchain with the most work and to do its best to ensure that its peers learn about what it thinks is the best blockchain, the network naturally achieves consensus without any sort of agreement and acknowledgment. By relying on nodes switching to use the valid blockchain with the most work, nodes will converge onto the same blockchain as eventually, one blockchain will have the most work.


I have waited for 2days now my transaction not confirmed yet

I can see that one of the transactions has been confirmed, so your problem is half solved. For the other transaction you just need to wait. If you're experienced enough you might as well want to rebroadcast the stuck transaction with a higher fee.
The problem
The transaction fee you have included in both transactions is way too low. At the current state of the bitcoin network, there is not enough room in blocks to fit all of the transactions, so the miners pick only the transactions with higher fees.
Prevent from happening again
If you require your transactions to be confirmed in a short period of time, then you need to include a much higher miner fee. You can use the following site as a guide as to what the fee should be:
https://bitcoinfees.21.co/


If this question is about the recently published bip-taproot proposal, the answer is no, you cannot use a v0 script inside a v1 output.

The general reason for this is that some of the goals the BIP is trying to achieve are incompatible with v0 scripts. That on itself doesn't make it impossible to support v0 scripts, but reasoning about the benefits of the changes is much easier if you know there is no way to bypass them. Furthermore, the changes between (the initial set of) supported features in v1 and v0 is small:

No CHECKMULTISIG The OP_CHECKMULTISIG opcode is unnecessarily inefficient, as it sometimes needs to try multiple combinations of public keys with signatures. Furthermore, it is not compatible with batch validation (the ability to verify all signatures in a block faster than verifying them individually). As multisig constructions are very useful, a replacement opcode is available: OP_CHECKSIGADD, which increments a counter based on whether or not a signature check succeeded.
Schnorr instead of ECDSA All opcodes that take ECDSA signatures in v0 are changed to take Schnorr signatures instead. They're more efficient, but also ECDSA does not support batch validation, conflicting with one of bip-taproot's design goals.
Improved sighashing Some improvements are made to the hash that's signed in signatures to resolve a few long-standing issues. If there was a way to bypass these improvements it would be hard for other participants in a transaction to rely on these fixes being guaranteed.


How do I generate multiple address with a master public key in pybitcointools?

You want to use bip32_bin_extract_key on the bip32_masterpublickey:

https://github.com/vbuterin/pybitcointools/blob/8e8a33d7281c871950519e5f256ad08cf0d5df69/bitcoin/deterministic.py#L140

And then use pubkey_to_address on the result:

https://github.com/vbuterin/pybitcointools/blob/8e8a33d7281c871950519e5f256ad08cf0d5df69/bitcoin/main.py#L446

simply put:

btc.pubkey_to_address(btc.bip32_bin_extract_key(bip32_masterpublickey))


An address is a shortened notation for a particular script. As a transaction output contains exactly one script, it has at most one address (it is possible that the script does not correspond to a particular address, though).

Due to historic reasons, a (normal pay-to-pubkey-hash) address is however also used to refer to keys (by giving the address that would correspond to a script paying to the hash of that key). The array that decoderawtransaction and gettransaction return as 'addresses' is an example of this. For a (non-P2SH) multisig address, if it is a m-of-n multisig script, it will decode the script, and give the keys it pays to (in address notation).


There's a command line electrum option convert_xkey. If you're on linux or macosx you can see the documentation for it via electrum help convert_xkey. Alternatively you can use the console tab of electrum on all operating systems to achieve the same result. For example convert_xkey(xkey="xpub...",xtype="p2wpkh") will convert from p2pkh to p2wpkh


During a IBD : Initial Block Download by a full node, from where is the blockchain downloaded?

Yes, they download blocks from other nodes they connect to.
In Bitcoin Core you have the choice between being a pruned node or not. In both cases all blocks are downloaded and fully verified, but in pruned mode old blocks are deleted after a while after being verified. This has a number of implications, but one of them is that a pruned node does not help new nodes perform IBD.


How do they put several bitcoins into a block?

By block they are not referring to the blockchain. They just mean that the 24,518 BTC will be divided into 12 different lots (or blocks) with each auction containing about 2,000 BTC.

https://news.bitcoin.com/ernst-young-auction-24-thousand-btc/

"Ernst & Young will be selling the confiscated cryptocurrency in auction form, allowing bidders to compete for 24 thousand coins in 11 lots of 2,000 BTC. One lot will amount to 2,518 Bitcoins,"


How much electricity and time would mining a bitcoin consume right now?

The amount of kilowatts needed to mine a bitcoin depend on the hashing your setting(rigs) can produce, so 15 000 kilowatts/hour of power is not a good metric

There is plenty of website that allow you to calcul if it can be profitable to mine bitcoin, based on your settings of 0.003 USD per kilowatts/hour yes it is

https://www.cryptocompare.com/mining/calculator/btc?HashingPower=40&HashingUnit=TH%2Fs&PowerConsumption=1500&CostPerkWh=0.003&MiningPoolFee=1


Are HD wallets private keys any different than regular private keys

Bitcoin uses ECDSA for signing and verifying. That is, G is a curve parameter (known constant), k is a number, then the public key is kG, etc. The same mechanism is used in different script types too: Multisig scripts and other P2SH scripts. However, note that it is easier to brute-force a P2SH multisig scripts, which is why the Bech32 format P2SH scripts have longer hashes. Similarly, P2SH scripts might not use signature validation at all.

An HD private key can be encoded in the WIF private key format, and any wallet supporting importing private keys would be able to spend its outputs. This doesn't hold true for other address types.


How does a wallet rebuild itself from its seed?

If by seed you are referring to a mnemonic phrase (12 or 24 words is common) then the process goes something like this:

The phrase is hashed (or some other process) to produce random or pseudorandom bytes we will call the "seed"
The byte array seed is passed into BIP32 HD master key algorithm to create a BIP32 master key.
Following a standard like BIP44, the wallet then derives sub-keys sequentially in order. Checking for transaction history of each key's output.
If left alone, this loop would last forever, so standards like BIP44 specify a "gap limit" which means that if gap limit = 20, then "If I generate 20 addresses in a row that all have 0 transactions in their history, I will stop checking addresses" For receiving paths, 20 seems common, for change paths 1 is standard.

Continue this loop until the gap limit is reached.

This type of methodology doesn't work for merchants or large exchanges, so the gap limit logic of "how far do we keep checking" may vary.

But most HD wallets rebuild themselves in this way.


Bitcoin Explorer - Truth or did i just got my wallet stolen?

According to a post by grue, the program from the website adds another executable to system startup, so it certainly behaves like a virus. You should get your computer checked.

Advise for the future - don't trust any .exe file unless you know the source or the owner. If you're not sure whether to trust someone or some website, ask either here, or on the forum. The community is quite sensitive about security and you can be pretty sure to get some good feedback if you ask.


What can be done if Bitcoin is used for money laundering?

In reverse order.
Can we close a criminal's account?

No.
The owner of a bitcoin address can move all the money out of the address and then delete all copies of the key pair for the address. This would amount to closing the account, as the likelihood of someone having the same address in the future is infinitesimally small. However, moving bitcoin money out of an address requires either the owner's consent or legal pressure brought bear on the physical human being assumed to own the account. Criminals are adept at avoiding this sort of pressure.

Can we stop criminals using Bitcoin?

No.
This would require network consensus to collectively blacklist a bitcoin address. At current the community would be very unlikely to endorse such a protocol enhancement; as it could be used to tyrannise minority account holders.
If such a consensus was reached, locating criminal accounts would be difficult unless all residual mechanisms of bitcoin anonymity were also outlawed at the protocol level. Might as well rename the currency "1984".
But
Until bitcoin can be used in large volume to directly purchase food, shelter, safety and bling; criminals wanting to enjoy their ill-gotten gains have to change their bitcoins into a mundane currency like US dollars. Currency exchanges are already improving their recording and accountability to law enforcement officials. So the criminal will need to launder the money through plausible revenue sources before cashing out.

What can we do if Bitcoin is used for money laundering?

Not much
People or businesses could snub money that has come from a proven mixer or other aggregate wallets that don't comply to some auditing standard. But if bitcoin grows to any meaningful size, that is a lot of banking services or aggregate wallets to trace and enforce.
Considering how disposable each bitcoin address is, a botnet could simply create a million temporary accounts; feed the dirty money in at random; mix about like a mesh network of transactions following a plausible traffic pattern; and then spit out clean money.
In the long term, law enforcement will have powerful forensic tools to infer most cases of obvious money laundering. In turn, criminals with the connections and wealth will rent advanced money laundering methods as needed - like they already do in Vegas*.

* If you are suitably paranoid, you have to wonder how many bitcoin casinos have been established specifically to gestate money laundering operations.


To validate transactions, Bitcoin uses Elliptic Curve cryptography. Specifically, an Elliptic Curve Digital Signature Algorithm (ECDSA) on the curve secp256k1.

ECDSA includes three important pieces of data. The private key (a large random number), the public key and a digital signature. These pieces of data have a mathematical relationship such that the public key and a digital signature can inexpensively be computed from the private key, but the private key cannot be computed inexpensively from either the public key or a single digital signature.

There also exists a mathematical relationship between the public key and a digital signature which allows anyone to inexpensively verify that a digital signature was computed from the same private key used to compute the public key. Knowledge of the private key is not required to know that a digital signature was computed from the same private key as the public key.

How can we know that a digital signature is authentic without knowledge of the private key?

By knowledge of the Elliptic Curve parameters and the four following equations...

(1) Qa = dA * G

(2) P = k * G

(3) S = k^-1 (z + dA * R) mod p

(4) P = S^-1 * z * G + S^-1 * R * Qa

where...

Qa is the public key,

dA is the private key,

G is the point of reference in our curve parameters,

P is a point on our Elliptic Curve,

k is a large random number (not the private key),

S is the second half of the digital signature,

z is the hash of the message being signed (encoded as a large integer),

R is the first half of the digital signature (and also the x coordinate of P),

p is a very large prime number defined by our curve parameters.

And then, by substituting (1) into (4) we have...

(5) P = S^-1 * z * G + S^-1 * R * dA * G

Factorizing (5) leaves us with...

(6) P = S^-1 (z + R * dA) * G

Now, substituting in (2), we have...

(7) k * G = S^-1 (z + R * dA) * G

Which can be simplified to...

(8) k = S^-1 (z + R * dA)

Lastly, we invert k and S leaving us with...

(9) S = k^-1 (z + R * dA)

Which is the equation first used to create the signature by the private key holder.

This proof informs us that if the x coordinate of P from (4) is equal to R, then the digital signature (R, S) was generated from the private key dA.

Please see here for a longer explanation and here and here to understand how ECDSA is applied in the Bitcoin system.


Creating a multisigaddress using public key from 2 different wallets or using public key from 1 wallet only? Which one is correct?

This is (unfortunately) the correct behavior in Bitcoin Core. This is due to how the wallet is structured and what it determines to be part of the wallet.

In order to be able to have the multisig address be "part" of your wallet, you need to import it using importmulti or importaddres. That way it will be added as a watch only address so the wallet will track transactions to and from it.


How to display a list of incoming bitcoin Transaction history in my own wallet?

But How can I get the incoming Bitcoin Transaction Details which are
  perform out side my wallet?

Unless you are using bitcoin-core wallet (e.g. listreceivedbyaddress), there isn't a way to query bitcoin-core for transactions by address. To do this, you will need to parse the blockchain and create your own database indexed by address.

An example implementation that can be used for reference is Bitpay Insight: https://github.com/bitpay/insight


Clearing 2 week old transactions from mempool

What stops Blockchain.info to rebroadcast my transaction to the
  network again?

Nothing. Or may be laziness.

  It would be exactly the same as if I just broadcast my transaction for
  the first time, right?

Right.

  If Blockchain.info can do it, is this 2-week rule true in the first
  place?

Everyone can do it. And someones definitely do it. Your node will get it back after 2 weeks.

  If it is true, how it is implemented on the network level?

It is not consensus rule. If you want - you have a right to rebroadcast a transaction if it is still valid [and not confirmed].

  Is it some kind of agreement that we do not rebroadcast transactions
  that are this days old?

No.


Bitcoin core 0.19.1 RPC, 'sendtoaddress' not working!

The main problem is the parameter blocksonly=1 in bitcoin config file. This prevents the node to broadcast transactions to the netwrok. I removed it and it works fine!


Why does the Bitcoin conversion rate change wildly?

As with any traded commodity the price largely depends on the confidence of the buyers and sellers in the future evolution of the price. Basically you pay whatever you feel it is worth. Like stocks this changes over time, as the company or the bitcoin economy in our case evolves.

The wild price swings are not that really that surprising then when it is mostly sentiment driven. Any sudden move in either direction may cause uncertainty, triggering reactive selling or buying that will again trigger more reactions. This cycle is then broken by people seizing the moment to buy in cheap or sell high, stopping the momentum, possibly triggering a move into the opposite direction.


Bitcoin, Ethereum and Litecoin value graph look very similar

The prices of basically all altcoins follows that of Bitcoin's. So generally when Bitcoin goes up, so do altcoins', when it drops, so do altcoins'. This is generally because altcoins are primarily used as a way for people to get more Bitcoin.


why bitcoin escrow don't use fiat currency?

Because it is much harder to do escrow with fiat.

Fiat currencies are subject to various regulations which make this difficult. The escrow service would have to be registered as a money transferring business and be required to follow AML/KYC regulations. This means that all users would have to submit personally identifying documentation to the service in order to do any trades.

Additionally, there are multiple ways that fiat can be transferred. If you look on LocalBitcoins' website, you will see that you can do a variety of things for transferring the fiat; you can send cash by mail, cash in person, you can do bank account transfers, you can purchase goods for the seller, etc. There are a lot of different ways to send the fiat to the other person. If they put the fiat in escrow, then they would be limiting the number of ways that the fiat could be transferred. Conversely, there is only one way to transfer Bitcoin.

Furthermore, doing a fiat escrow would mean that the service is subject to whoever they are using as their bank. The service itself cannot actually hold the fiat money when it comes to things like bank and wire transfers (or it's really difficult). Rather they have to have an account with a bank and the money would go into that bank account and leave from that bank account. This introduces another third party who is not necessarily trusted. That bank could shut down the service's bank account thus causing all users whose funds are in escrow to lose all of their funds. It would, in general, introduce more risk to trading.

Lastly, the idea of services like LocalBitcoins is centered around the idea of trading Bitcoin for physical cash, typically in person. This means that it is extremely difficult to provide escrow services because someone from LocalBitcoins would have to be physically present for each trade to hold the fiat while the Bitcoin transfers. That would simply be unfeasible and impractical to do. However, because Bitcoin is a digital asset, the Bitcoin can easily be held in escrow on their servers and the trade can go along as long as both parties have internet access. This is much easier and cheaper to do.

Thus Bitcoin is easier to do escrow with than fiat, so such services escrow the Bitcoin rather than the fiat.


What is the best suitable transaction fee to avoid high fees but still get confirmed?

First a clarification: Anyone giving a flat fee in response to this question is not giving sufficient information. Transactions are (generally) selected by fee rate. This means that besides the flat transaction fee that was included, the weight of your transaction plays a critical role:

fee rate [sats/vB] = transaction fee [satoshis] / weight of transaction [virtual bytes]

In order to get a confirmation, you need to successfully compete with the other waiting transactions for block inclusion. Depending on your time preference, you either have to place your transaction within the top 4,000,000 weight units of the block author's mempool sorted per transaction fee rate, or be willing to wait until blockspace demand cools down a bit to drop to the fee rate that you're willing to pay.

There are a number of services that attempt at predicting appropriate fee rates for various inclusion times, e.g.:

bitcoinfees.github.io
whatthefee.io
bitcoinfees.earn.com
@corefeehelper (tweets Bitcoin Core fee estimates hourly)

There are also sites that give perspective on the mempool to facility users picking their own fee rates, e.g.:

jochen-hoenicke.de/queue/#24h
https://btc.com/stats/unconfirmed-tx

Finally, there is a general lower limit, the minRelayTxFee (which despite the name is a fee rate), for which the default currently is 1,000 satoshis per kvB, or 1 satoshi per virtual byte. Sending a transaction below a node's minRelayTxFee will cause the node to drop it from their mempool instead of relaying it, i.e. such a transaction will generally never get to the miners, and won't get mined into a block even when blocks aren't full.

Conclusion: If you have a low time-preference, e.g. in the case of creating consolidation transactions, and blocks haven't been consistently full, sending a transaction with a fee rate of 1 satoshi/vB will pay the lowest fees which will still get you confirmed.


how does bitcoin's 6 confirmation really help?

Generally, all confirmations are relativistic: any chaintip could still be replaced with a heavier chain! However, reorganizations become increasingly costly and unlikely the more proof of work is piled on a block.
You are right, an attacker exerting a majority-attack can censor or rollback any transactions, and thus perform a doublespend-attack to return a payment they previously made to another party to themselves (also see What can an attacker with 51% of hash power do?).
If you are receiving payments that are orders of magnitudes larger than block rewards, you should consider additional precautions (e.g. KYC, collateral, waiting for more confirmations). The occurrence of a sustained majority attack on Bitcoin could be considered a fatal scenario for Bitcoin: no transaction could be trusted anymore at any number of confirmations.
You may have read that Bitcoin requires the majority of the hashrate to be "honest" to work. Honest in this context means "not collaborating to attack the network" or "independently creating good-faith blocks". Fortunately, it is rather expensive to control the majority of the hashrate. Each block reward is currently worth about $70,000, so a six block majority attack would likely cost $350,000+ in electricity cost alone. Additionally, it would require access to a majority of highly coveted and expensive hardware. Industrial Bitcoin miners have made enormous investments into application specific integrated circuits (ASICs), which can be used for nothing else than SHA-256d mining. The most likely way for a majority attack to come to pass on Bitcoin would be for someone to take over the mining controllers of multiple of the largest mining pools. I would hope that this would be discovered and remedied quickly.
That is not to say that your majority attack scenario hasn't come to pass before. Especially minority forks of larger networks, or other coins that use the same hashing algorithm than bigger networks have been majority attacked in the past. For example Bitcoin Gold was attacked with a 1,300 block reorganization in January 2020.


Is it possible to generate(mine) a block with specific transaction via bitcoin-cli on regtest?

When you run generate, it mines a block with the transactions in the mempool:

generate nblocks ( maxtries )

Mine up to nblocks blocks immediately (before the RPC call returns) to an address in the wallet.

If you want those new coins to be mined to a specific address, you can use generatetoaddress

You can create transactions and submit them to the mempool either using the wallet RPC, e.g. sendtoaddress or using the rawtransactions RPC:
e.g.

createrawtransaction
signrawtransaction
sendrawtransaction

sendrawtransaction will put the transaction in the mempool, which can then be included in the next block using generate


Are there any implemented ways for turning addresses into human-readable word(s)?

No

If not, why?

Because, copy-pasting works and no one has proposed a method for something that no one I'm aware of has needed.

I.e., are there any known technological issues in implementing this?

No


Same entity controlling separated parts of a a lightning path

The preimage R is the same throughout the entire route, so Bob/Dave would know what R is (from lnd Overview).

However if Bob were to broadcast his commitment transaction for the Bob -> Carol channel, it would have to either be an old commitment without the HTLC-offered output or be the current commitment transaction with the HTLC-offered output. In the case of an old commitment transaction, Carol would be able to claim all of the funds in the channel with the revocation key for the old commitment transaction.

In the case of the second transaction with the offered HTLC output, the offered HTLC output has a timeout on it which prevents Bob from spending the funds for some amount of time, say two days. In that time, Carol could redeem those funds with the preimage R.

In order for Bob/Dave to pull funds from Carol in the Carol -> Dave channel, he would need to give Carol R before the HTLC between Carol and Dave times out. The timeout of this HTLC will be shorter than the HTLC between Bob and Carol (e.g. only 1 day) so when Dave gives Carol R to pull his funds (or R is published in Dave's broadcast commitment transaction if he does that), Carol can then use that R to claim her funds from Bob's offered HTLC output.

In the event that Dave decides to not pull funds from Carol, Carol retracts her HTLC output after it times out and does not lose any money to Dave. She does not then gain any money from Bob and thus has not lost any money at all.

If Dave refused to sign the new commitment transaction, Carol broadcasts her commitment with the Carol -> Dave offered HTLC after the timeout passes and publishes a transaction which spends the offered HTLC output using the HTLC-timeout transaction. If Dave tries to spend the HTLC using R, Carol then learns of R and can then spend Bob's offered HTLC output using said R. In that case, Bob/Dave can actually lose money because Carol's HTLC-timeout transaction could confirm before Dave's HTLC-Sucess transaction (which contains R) and her HTLC-Success transaction for Bob's HTLC could confirm before Bob's HTLC-Timeout and thus gain money from Bob/Dave.

Thus such a scheme would result in Carol effectively being cut out of the route and not losing any money. If Bob/Dave were stupid, they could actually lose money to Carol.


What are the advantages and disadvantages of pooled mining?

Disadvantages of pooled mining:

Smaller expected earnings - pools usually charge a fee and sometimes use a reward system (like Pay Per Share) that can give you a lower payout.
Having to rely on third party system to earn your money - websites go down, and when they do, your miners can be idling.
Trust - you have to trust the pool owner not to swindle money from you, either by creating fake miners in the pool that do no work but still receive rewards or otherwise. Similarly, the pool owner can have an agenda of their own that they wish to further (for example, Eligius pool owner used their miners to attack an alt-chain, as well as putting prayers in the coinbase transactions).
Giving power to the pool owner - some important decisions regarding Bitcoin future are made by people voting with their blocks. Some time ago the Bitcoin community had to chose between two BIPs that fulfilled the same role. The voting was done by the coinbase transactions containing a vote for either one of the BIPs. By giving their computing powers to the pools, the miners essentially gave their votes to pool owners to vote as they chose.

Advantages of pooled mining:

More predictable payouts - pools usually pay you on a more regular schedule - be it once you reach a certain threshold, daily or the like. Solo mining only pays you when you find a block, which can take a few days, years, or never.
Extra features - Pools usually let you quickly check the status of your miners from anywhere, notify you of payouts and the like, which would take you a lot of extra setup time on your own.
Less space - If you are solo mining, you need to keep your own copy of the blockchain. Pools handle all that by themselves.
It is easier - There is a low less setup required to do pooled mining, especially when we are talking about merged mining and so forth.


Is it normal for my hardware hashrate to vary by 15% but still achieve the advertised average?

I have TechnoBit Hex miners running BlackArrow ASIC chips and my equipment fluctuates a lot. I mine with the 'Discus Fish' Pool (aka F2Pool) and they let me view my hashrate on their website on a really fancy graph. My 1200 GHs dips from 900 GHs up to 1300 (occasionally), but in the end I do get a nice even 1150 / 1200 GHs.

The software (Cgminer) does fluctuate even more on my screen, it goes from 700 to 1300 GHs, but this really depends on what difficulty your miners are getting from your pool. Anyhow, a little fluctuation is perfectly normal.


What can be done in order to improve privacy in bitcoin transactions?

Pieter Wuille posted an answer earlier today that covers some of what is already being explored in the pipeline for additional privacy.

  ... but improvements are continuously being worked on (search for things like MAST, TumbleBit, Layer-2 payments, Taproot, signature aggregation, scriptless scripts, confidential transactions, ...)

In addition, further ideas like change obfuscation have recently been seen on the [bitcoin-dev] mailing list.

There will no doubt be even further suggestions in time.


Why, how, and when should an intermediate LN node terminate/resolve its HTLC(s) off-chain?

First I would recommend to read BOLT2 in the section normal channel operation in order to understand exactly how and when htlcs are resolved. The whitepaper is heavily outdated and only explains the principles.
That being said the problem of your question remains.
To answer your question : intermediate nodes should resolve HTLCs as quickly as possible but that depends on the outgoing peer.
Let us assume the following path :
A-->B-->C-->D
As soon as D resolves the HTLC off chain C should resolve with B. And B should then resolve with A. The problem occurs if A stops talking to B. In that case B cannot resolve its HTLCs while it paid C who has was reimbursed to pay D before. Unluckily B can only resolve its HTLC with A after it resolved the HTLCs with C. The idea of doing it the other way around would not work and remove the trustless property of the routing.
In theory this should not be a problem for B as B can trigger a force close of the channel and resolve the HTLCs onchain.
This however yields several practical questions which can lead to the described attack:

what if the timelocks of the HTLCs expire soon? (Then A can claim those time locked outputs)
what if the mempool is full and fees are high? First B has to pay those fees in order to get its HTLC included and settled however once the timelock is over A could also claim those outputs with higher fees. In case A and D collaborate A has as much money as the HTLC is worth.
getting the commitment transaction in before the htlc timelock expires might become tricky as the fees of commitment tx are prenegotated and if A stops talking can't be adopted.

The third point might lead to the scenario of the second which can lead to the first. In such cases weired effects can happen and B can lose its funds that are in the HTKC as B has paid C but won't get reimbursed by A even though it has the proper signed onchain transactions.
A node generally does not want to force close the channel as that is expensive. Especially if that nodes expects to claim htlc outputs. However if the htlc timelock gets to close the node should consider to already close the channel to get the commitment txcinfirmed and be better prepared in the sense of having a time window to to get its HTLCs resolved without A being able to interfere.
Sorry that I can't give you a definite answer here. That is exactly part of the problem / attack and makes it so subtle


How can other currencies be "issued" via Bitcoin?

If you are quoting correctly, he is 100% incorrect, and he should've consulted an old white man first.

"Issuance" as defined by economics and more importantly by law is the creation of a liability by the liable.  The Bitcoin blockchain is not liable for Federal Reserve debts, in this case US Dollar banknotes; further, the Bitcoin blockchain has no power to create a liability owed by the Federal Reserve; therefore, the Bitcoin blockchain has no power to issue US Dollars.

Now, if it's a slight misquote, that the Federal Reserve could issue USD via a cryptocurrency implementation, that is 100% correct and would be a superior depository management system.  Of course, the Bitcoin code would have to be altered and centralized to provide this functionality, but the point remains.

It would be superior for central banks to manage deposits with cryptocurrency implementations because the accounting can be made 100% accurate, and the security is bulletproof until the digital signature algorithm is broken.  Costs would plummet, but gov't agencies rarely are concerned with cost...nor revenue for that matter.


about bitcoin market price for a shopping mall

There is a simpler option than to re-tag your products every day to keep up with ever changing prices. You could denominate the products in USD/EUR/... and advertise that you are accepting Bitcoin. Then you update your point-of-sale software to be able to do the USD/EUR/... to Bitcoin conversion on the fly, with regularly updated exchange rates. This way you always keep up to date, can give information on the current price in Bitcoin and accept Bitcoin payments, all while keeping the price tags stable.


How can a noob understand 'where their money went' when buying from bittylicious?

From the transaction link provided (link)

You can see that fees was just below $2 for this transaction:

So the rest (about 18 pounds) have been taken as a commission/fees for using their interface.

I would suggest you to try some other website to buy BTC, as you are paying a very high fees to buy BTC.


You simply can't 'revoke' transactions. If the output defines a 2-of-3 restriction, 2 of the 3 keys must sign the transaction spending it. If no two parties will agree to sign a transaction spending the output, the money is simply lost.


For the Noobs: Starting Bitcoin games. I cannot transfer Bitcoins, or use Faucets

Remember that the sender pays a fee.

That seems to be your problem. According to this info, if your transaction output is smaller than 0.01 BTC, you need to pay a minimum 0.0001 BTC transaction fee. Since you only have 0.00008 BTC, there are not enough funds to make the transaction (note also that the minimum fee is over 6x the amount you're trying to transfer, so it might not be a good idea to do so).

As for your other question, your game seems to be uniquely identified by that URL, so sharing the link would allow someone else to continue the game for you (and lose your money). I'm not really sure how the mechanism behind this works, though...


Can a two-block-sized chain override the main chain?

No, it would have to be much longer.

Besides the fact that there are checkpoints, the difficulty of a block is defined by its target value, not the actual value of the block hash. The block hash just has to be less than that target value. So you would need to make the target value be very small (i.e. make the difficulty very large). In order to do this, you would need to mine at least 2016 blocks to trigger a difficulty adjustment. But difficulty adjustments are capped at being no more than 4 times harder (and no less than 4 times easier) than the previous difficulty. So you would need to trigger many difficulty adjustments in order to get your difficulty up to the necessary value.

Once you get your difficulty high enough, yes then you could mine a block which has a higher difficulty than the sum of the entire blockchain's difficulty, and then nodes will accept your blockchain (assuming you started from the last checkpoint).

However doing this would be extremely computationally infeasible. In order to mine said block, you would need to have the sum of all the mining power at each block in order to mine one of these large difficulty blocks. What this means is that if block 1 was mined by one machine, and block 2 was mined by the same machine, then you would have to have at least two of those machines in order to mine a replacement block 1 that has a higher difficulty than the sum of the difficulties of blocks 1 and 2.


When (or) do ICO tokens go to an exchange?

It is not possible to know such things unless an exchange announces that they will be listing an ICO or if the ICO creator announces that an exchange will be listing an ICO. An ICO being listed is not automatic; humans are involved. In order for an ICO to be listed on an exchange, the exchange operator must manually add it. This can happen either if an ICO becomes extremely large (although there is no guarantee that a large ICO will be listed by an exchange) or if the ICO creator asks exchanges to list the ICO.

The only way to know whether, where, and when an ICO will be listed on an exchange, you will need to follow any announcements from the ICO and from all possible exchanges that the ICO may be listed on.

The same applies for altcoins.


Could someone solve for your private keys by sending many transactions to the same address?

So there are attacks where if you sign enough times with the same private key, the attacker, with access to a side-channel can figure out your key.

So if you were signing with your private key a lot of times, this would make your private key slightly less secure. If you're receiving bitcoins to your address, you're not signing with your private key, so this isn't an issue.

The more important consideration here is that you lose privacy with address reuse.


I forgot what wallet is connected to an address. Is there anyway to figure out at least what wallet i used ?

No, the address doesn't tell you anything about the service or account. The only way to find the payment is by checking each wallet.


What other lightning nodes are there besides Eclair Core for running a full node lightning?

There are a few lightning network full node implementations, that follow the LN specifications. Note that in many ways the specs, and software, are considered experimental, and should be used at your own risk.

C-lightning is written in C
LND is written in Golang


Get simple BTC value to insert it in excel sheet

This more of a question about excel than it is actually about Bitcoin. But the answer is actually pretty easy.

The first thing is that the data that you want to import from the web may not be easily isolated, so you might have to import much more data than you want into a second excel sheet, then link the cell with the data you are interested to a cell in your actual sheet.

Follow these steps:

Find a site that has the dynamic data you are looking for. Let's use Bitstamp.
Copy the data that you want and paste it into excel. You can't miss the current price right at the top.
After you paste it into excel the little paste options icon will popup next to it. Click it then select Refreshable Web Query.
A new window will popup that will load the whole page. You might get some script errors; you can ignore those.
The window directs you to click the arrow icon next to the table that you want to import. Unfortunately, with BitStamp, the only option is the whole page. Click the arrow then click import.
Excel will now import a load of data from the webpage. The second cell is the one we are looking for; that is the current Bitcoin price in USD. This is where have a separate sheet for this import data is convenient.
Go to the sheet where you want to use that data and link the cell you want to the other by first clicking = then clicking the cell in the sheet with all the data from bitstamp. You will see something like =Sheet1!A2 in the formula bar.

That's all there really is to it. Microsoft has an extensive article on the topic complete with all the technical details.


Is there a way to distinguish miner nodes from other nodes?

Yes, but only in a probabilistic way: If you run many different nodes and try not to leave any node in the network that isn't connected by any of your nodes, you'll be able to track and visualize the relaying of the new blocks. After a while, you'll have the whole network graph, looking at which might obviously show the miners.

By the way, using the same method, it's possible to find the authors of transactions, which is what Dandelion is aiming to solve.


That error means you did not provide a high enough transaction fee on your transaction.


If this is what you are proposing:

Address A: 1Axyz...
Address B: 1Bxyz...
Address C: 1Cxyz...

Tx1

A -> Multisig requiring 1 of 2 signatures from pubkeys of B & C

Tx2

Tx1 output 0 -> OP_RETURN

Then yes, that's totally legal on the blockchain. Not sure why you would want to do it, though.


Is there a service that automatically "sweeps" funds to another address whenever they are sent?

You could make one using bitcoinj which listens for txns, then triggers a spend.
Perhaps you would use rpc to control bitcoind to make the spend, and only use bitcoinj for the listening side ?
That should (I haven't done it but hope to soon) not require any private keys to listen to the wallet.
See this: Listening to all transactions of the Bitcoin network

bitcoind appears to be pull oriented, while bitcoinj can be set up to be push related, sort of.


What concerns arise from the heavy miner concentration in China?

I do not think it is not as simple as having 51% of the Hash power, and immediately causing "havoc".

The power of more than 51% of the Hash power comes from the ability to create an alternate chain of greater difficulty than the public chain.

A Secret Pool that has more Hashing Power than all the known transactions could be working on a fork in secret, and could unveil that forked blockchain at some point, declaring it to be the "one true chain".  This could create double-spends, and reverse earlier transactions, and otherwise cause chaos.

But the other miners would have to accept this mysterious, much longer chain that suddenly appeared.  That seems unlikely.

We know that forks and orphan blocks are part of the mining process, and maybe could even deal with a forked chain of 4 or 6 blocks.  But if a mysterious blockchain suddenly appeared that was at serious odds with the public chain (dozens or hundreds of blocks long), everyone involved would very likely reject it.   The rogue miners would then have invested substantial hash power, costs, and opportunity cost for a chain that ultimately may get rejected.

I'm not saying its an entirely impossible attack. But such an attack would have a substantial risk of failure.  It's much easier and less risky for someone with that much hashing power to just earn an honest living through honest mining.

As long as the Chinese Miners are regularly submitting blocks to the public chain, we can be reasonably confident they are not working on another forked blockchain in secret.


The Bitcoin Core wallet and the LND wallet are completely separate wallets. LND relies on Bitcoin Core as a source for the blockchain data, nothing more.
The profitability of your node depends on where it is situated in the network's topology. If you want to run Lightning to earn money, you will need to pick reliable nodes as channel partners, but also try to connect some distant parts of the network, or situate yourself on shortest paths in other ways. I don't think it's possible to give a blanket recommendation for fees. You may find this talk from the Chaincode Lightning Residency useful: transcript, video. Then maybe just start with the defaults, look around what others are doing and experiment a bit. You could also pop into the Lightning slack and ask the present experts for advice on that.
Generally, just play around with it a bit, don't worry too much about the proft when you're just getting started. Familiarize yourself with the wallet setup and figure out the backup situation (static channel backups) first. Don't put too much money on the line, it's a hot wallet.


Why can't bitcoin miners modify transaction outputs?

What is signed in the input scripts?

Depends.

The case of a P2PKH spending transaction, the scriptSig (input script) for each input will contain a ECDSA signature and a byte which donates what exactly was signed called the SIGHASH flag. In almost all cases this is SIGHASH_ALL, which means that the signature covers the entirety of the transaction outputs and inputs, less other signatures. If the transaction output script is modified and any input has signed it with SIGHASH_ALL, that signature would be invalidated and the transaction can not be included in a block.

Other flags can have the effect you describe, if I make a transaction which only signs a single input with SIGHASH_NONE (this signature only covers the input), then anybody in the network is free to modify the outputs as much as they want before it gets buried in a block. Nobody uses it like that for exactly this reason.

There's two other flags available today SIGHASH_SINGLE and SIGHASH_ANYONECANPAY. The former allows you to sign only one of the outputs and ignores the rest (eg vin:1 signs only vout:1), however this is buggy and not at all intuitive. The latter allows you to make transactions where the inputs are a wildcard, spend this output to this script, and make up the deficit using whatever other inputs you want.

In general nobody uses SIGHASH flags, the majority of all transactions are strictly SIGHASH_ALL.

  I am not very sure what the script of the inputs contain, but I guess it should contain the public key, and a signed message.

This depends entirely on what type of output is being spent, but we'll assume it's a very typical Pay to Pubkey Hash (address) transaction. In this case the scriptSig is extremely simple.

304402204bc6ed9b0122fc145031d4d9f6a30fbb28b63d152e3848c785a65f1e0b97ea8d02205a99bc13ba9293526ed175947cb756c5e3fca0a98890b88551e3e6c4c0bb6f5601
04988b34239b2f1c2441db4d50911b0550350414ce00b88f8dd39964f1a8631824db8e78b61d0ea6f3d9fcffcf2cd20be7d88a1583854682db4d136acd08542c3d

We have two data items, the first is an ECDSA signature in DER format, and the public points of the P2PKH output we are spending. The last byte of the signature is the SIGHASH flag, which in this case is 0x01 or SIGHASH_ALL.

If you want to follow along with how these structures work, webbtc.com has a great script visualization tool which will allow you to see how these go together. In particular here is a reasonable example transaction with one input and output, and here is a play through the script execution which does a good job of explaining how and why it is valid.


Unable to construct a correct raw transaction for bitcoin cash testnet

Bitcoin Cash does not use the original Bitcoin sighash scheme (which looks like what you're trying to do here).

Instead, it uses a variant of the sighash scheme that was proposed in BIP143 (which is used for Segregated Witness transactions in Bitcoin).


Signing transactions with un/compressed key

compressed pubkey and uncompressed one have different hashes. so, your code should be something like:

scriptSig1 = "76a914" + hashedPubKey_1 + "88ac";
scriptSig2 = "76a914" + hashedPubKey_2 + "88ac";


If a fundamental bug is found in bitcoin

Bitcoin is mainly two things

A set of Network protocols and associated rules by which Bitcoin wallets can interact with each other and by which mining software can interoperate with other bitcoin software.

A reference implementation of a Bitcoin wallet. This is the "bitcoin core" software application.

Network Protocol
Exploitable weaknesses in the network protocols and rules can be fixed by a soft fork which changes or extends the protocols or rules.
Software

this software that only has one version is running for 10 years without even a bug?

See the release notes for bitcoin core
for example, the notes for 14.3 include

Denial-of-Service vulnerability CVE-2018-17144 ——————————-
A denial-of-service vulnerability exploitable by miners has been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended to upgrade any of the vulnerable versions to 0.14.3, 0.15.2 or 0.16.3 as soon as possible.

Other implementations (e.g. Electrum) also have exploitable flaws discovered and fixed from time to time.


How to store transactional information on the blockchain

OP_RETURN is meant to store extra data on the blockchain. As fees are per kbyte, you'll be paying more fee.

Remember that block size is limited (1MB now every 10 minutes, but growing) and fees are expected to go up quite a bit, so if your application needs to be able to scale, you really need to do some calculations whether yours is a viable solution at all (in general: it should be much cheaper and easier to store extra data yourself, instead of burdening the whole world with it).


How does Bitcoin decide which Alert messages to forward?

As described in the Alerts article on the Bitcoin wiki:

  Only alerts that are signed by a specific ECDSA public key are
  considered valid. A copy of the private key is held by at least
  Satoshi, Gavin, and theymos.

All alerts that have not expired are relayed but the client displays only the highest priority alert that hasn't yet expired and wasn't cancelled, I believe.


How does blockchain.info get the addressbalance / seen date?

I'm actually working on doing this. To get the balance of an address you have to scan the entire blockchain. This can take a while but blockchain.info returns the balance instantly, which means they've already scanned the entire blockchain and are tracking all addresses. That's a lot of data to store, several gigabytes worth.


I found the easiest way to do this (version 0.12) is to issue the command (not case sensitive):

bitcoin-cli getblockchaininfo

Then, compare the blocks received field, to the headers field. The blocks received should increase steadily until it matches the headers field, at which point the client is synced.

Once the client is synced you can check if the client is accepting inbound transactions by issuing the command:

bitcoin-cli getconnectioncount

If you have 0 connections, something is wrong. If you have 8 connections, then it means you are only doing outbound connections (which might be the case if you just want to use your client to execute your own personal transactions, not verify everyone else's). If you have more than 8 connections, then it means you are accepting inbound connections and are acting as a full node (good for you).

Two additional ways to get information about your node is to use GetNetTotals which returns information about network traffic, including bytes in, bytes out, and the current time, and GetNetworkInfo which provides information about your connections to other nodes.


If you go to BitcoinCash's site, you can see there are multiple implementations of the bitcoincash protocol.
You can select any one, say BitcoinABC.
On their page you can find source code as well as binaries for your type of system which you can download and run.


Why does Bitcoin uses a Script language?

Yes it does use a language called script. The transactions have both a locking and unlocking script and it is there to allow the specification of simple conditions for spending so that transaction validation is not based on a static pattern and allows the spending of money to be programmable. The locking script normally contains the public key hash while the unlocking script normally contains a digital signature. The scripting language also caters for more complex multisignature scripts. If you just limited the processing to a signature verification then it would not allow for richer functionality and multisignature functionality.


I have lost my blockchain password and recovery phrase, how can I recover my wallet?

Please note, you are probably refering to the blockchain.info wallet service. Not the blockchain itself.

I don't think it is possible to recover your funds if you lost your password and your recovery phrase.
You should have secured your recovery phrase somewhere where it can't get lost or destroyed. A phone isn't a good place for that.

Read here more for detail: https://blog.blockchain.com/2016/04/20/support-team-tips-why-your-wallet-recovery-phrase-is-so-important/

Next time, write it down on paper or store it encrypted on a cloud service where nobody other than you can access it.

You can try and contact support on blockchain.info, but I don't think they can help you as your private keys will probably be encrypted with your password and can be recovered with you recovery phrase. But as you don't have any of them, I think recovery of your funds is not possible.

For more on this, read here: https://support.blockchain.com/hc/en-us/articles/211205343-I-forgot-my-password-What-can-you-do-to-help-

It may be a bit salty, but learn how to deal with security and secure your passwords, use 2FA and save your recovery phrases and anything else in a secure place. This should be done for everything, not only the blockchain.info service.

COMMENT: Yes you can recover your funds without the password and wallet ID.
You can do that by requesting your wallet ID as a first step using your e-mail at this link https://login.blockchain.com/#/reminder, second step is to download the wallet.aes.json file and then its possible to brute force the password. A possible script for doing that can be found here: https://bitcoin.stackexchange.com/a/3037/46677


How does a transaction using a Bitcoin payment code BIP 47 look like on the blockchain?

BIP47 transactions look like any other transactions as far as inputs/outputs & fees are concerned. There is no difference.

Payments are not sent to the payment code itself but rather to addresses generated by the shared secret of both the sender's payment code and the receiver's payment code.

The only recognisable trace on the blockchain is the notification transaction, of one payment code to another, which includes an OP_RETURN. Notification transactions are done once for a sender to a receiver to initialise the payment "channel" and also permit any future restore of the wallet directly from the blockchain (in the event of lost metadata, for example).

https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
https://github.com/SamouraiDev/BIP47_RPC


Is it possible to derive bitcoin adress from blockchain.com id?

No. The Blockchain.com ID is simply a random ID number that points to an encrypted copy of your wallet. Their support will not be able to help you find the addresses or gain access to the wallet even if they wanted to.
Unfortunately, if you've lost your password and your recovery key, and you can't find any backup copies of them, you're probably out of luck.


How does Ethereum domain registration works?

So the whole point of a name reg contract is not to send transactions, rather its sole purpose is to build up a database which other nodes can then query.

Ethereum smart contracts have immutable storage. This means that you can prove your primacy to a specific name, and other people can then reference that as part of a database.

What it comes down to is the credence other entities hold towards a specific name reg Dapp (Network effect, utility, what service it is registering names for etc). In some situations people would want a name reg for a specific purpose, say a list of Escrow contracts for one company, this could then be used internally, or shared. In others as you mention in your question, people would rather look towards a singular name reg which controls a DNS service.

You can have a look at an example name registration smart contract here: https://github.com/ethereum/dapp-bin/blob/master/namereg/namereg.html

Hope you find this useful!


Flooding mempool with fake high fees transactions

I see the question you have, and thought I put some more info in this reply, cause comments are too short.

You seem to postulate, that it might be possible to spam the net, by sending messages with high fee, and you consider this as a possible attack vector (with "fake transaction").

To understand how the network works, it is essentially necessary to look into the validation rules of transactions, when they are sent over the network. The fees are calculated by substracting the output value from the input value. If it is above 0, then ok, else invalid.

As a particular person anyone can craft a malformed tx. The question is now, how could you do this? Again, looking at the rules, it seems impossible. When you send it, the receiving nodes and all other full nodes will verify this tx. If the tx is malformed, they will reject it, and your node will be marked as a node, which sent wrong data into the network. At a certain point in time your node will get added to the blacklist of each full node, so this malfunctioning node cannot disturb the network further.

So you would need to find a way on how to send invalid tx to other full nodes, and as Andrew and Osias replied, to the current knowledge this is impossible.