Bitcoind with ZeroMQ support I'm trying to compile from latest tag the bitcoin repo and in my use case scenario ZeroMQ support would definitely help me.

Reading the documentation I realized this rudimental docker container. The Dockerfile installs the libzmq3-dev dependency and I define these configurations in the bitcoin.conf file.

The result is that inside the container there isn't any bind for the defined mq enpoints and I cannot realize where the error is.

Could someone please help me to enable mq publish mechanism?

Update: Now the bitcoin.conf file used is this running in in debug it logs this debug_log.txt.

So after some investigations I realized that ZMQ support is not present on the latest tag on the repo (this line was in charge of giving me the latest tag).

So I think that my problem is by now resolved by using master as building branch.

Thanks at all,
Dario.


How long does it take to download the blockchain? It's been over a day and still going I'm a newbie to bitcoins, and need some help!

I downloaded the Bitcoin client and installed it on my laptop.

It is 'Synchronizing with the network' and has been doing this for over a day. Is this normal? I have broadband internet and sometimes download large files in a resonable amout of time so I'm pretty sure its not my internet connection speed.

I understand it is downloading the blockchain thing bit by bit but does it really take this long? Will I have to do the same if I were to change laptops or get a new computer?

Also, whilst it is 'Synchronizing with the network' it totally slows down my laptop, so much so that it takes ages to even launch my internet browser. Is this normal? Will it always do this when I run the Bitcoin client, i.e. slow the whole system down, or is this only the case when it is 'Synchronizing with the network'?

Many thanks!!

You probably don't want to download the blockchain

The blockchain currently weighs in at about 144 GB (check current size)
Assuming you have solid 2 megabytes per second download speed, it would take around 20 hours just to download them.
In practice, this takes much longer, as your computer will verify every block individually, which takes some time.

Also, if you're not doing any mining, it may be wise to look into a lightweight client such as MultiBit or Electrum.


Can't find an API which gives me a full list of cryptocurrencies ordered by market cap I need to know the top-10 crytocurrencies ordered by market cap so I am looking for an api that returns a list of coins ordered that way.
Does anyone know?

Take a look at this website. I think it what you're looking for.


It it posible, pros and cons using multiple pass phrases on same blockchain? new to crypto, from what I can tell so far, the pass phrase is equivalent to knowing the private key. If this assumption is true -
In theory and for example, what are the pros and cons creating a new pass phrase/private key for each new $1,000 invested/earned, if possible ? (In the best case, this happens infinitely).

Yes, there is no limit on setting up multiple wallets. The main disadvantage is that you will need to keep track of numerous separate sets of funds. While it has advantages not to put all your eggs in a single basket, you may want to focus on just a few separate storage solutions for each of which you invest some more time to set up securely.


How do you get the OP_HASH160 value from a bitcoin address? I'm trying to sign a coinbase transaction. I know I need to use 76 A9 14 (HASH160) 88 AC but I don't understand how to create the HASH160 (20 byte) from a bitcoin address.

Check the Wiki. I think what you are looking for is point 3:

  How to create Bitcoin Address

  0 - Having a private ECDSA key

  18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

  1 - Take the corresponding public key generated with it (65 bytes, 1
  byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes
  corresponding to Y coordinate)

  0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

  2 - Perform SHA-256 hashing on the public key

  600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408

  3 - Perform RIPEMD-160 hashing on the result of SHA-256

  010966776006953D5567439E5E39F86A0D273BEE

  4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main
  Network)

  00010966776006953D5567439E5E39F86A0D273BEE

  5 - Perform SHA-256 hash on the extended RIPEMD-160 result

  445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094

  6 - Perform SHA-256 hash on the result of the previous SHA-256 hash

  D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30

  7 - Take the first 4 bytes of the second SHA-256 hash. This is the
  address checksum

  D61967F6

  8 - Add the 4 checksum bytes from point 7 at the end of extended
  RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin
  Address.

  00010966776006953D5567439E5E39F86A0D273BEED61967F6

  9 - Convert the result from a byte string into a base58 string using
  Base58Check encoding. This is the most commonly used Bitcoin Address
  format

  16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

You can check your calculations against my testing suite.


How is a block solution broadcasted? As we know there are scores of mining pool around the globe but some are pretty big ones such as Antpool, Poolin, BTC.com etc. with majority of them lying in China https://www.buybitcoinworldwide.com/mining/pools/. I have few questions in the broadcasting regard:-

If a solution is found by a miner, does the miner have the control to which nodes is it broadcasted?
If it is broadcasted based on the location of miners, then won't all the miners in the pool have an intrinsic advantage of their pool peers validating the solution?
Let's take a case when there are two solutions being broadcasted at the same time, one from the USA and another from China. Since, a lot of miners are there in China, Mongolia, Russia etc. doesn't miners in China have a better chance of getting consensus?
Also, what do we mean by consensus in the above case? Let's say the USA solution reached 20% of the active miners and the Chinese solution reached 80% of the  miners. As per my understanding even the USA solution could reach more than 51% consensus(more than 10% of globally active miners agreeing with the solution). Shouldn't there be a threshold on the minimum number of global miners agreeing with your solution given this large pools existence?

Thanks in advance! :)

If a solution is found by a miner, does the miner have the control to which nodes is it broadcasted?

Certainly, they can control the first level of peers they broadcast a solution to. However, they have no control over which peers will receive the block from the peers they have sent it to.
It is in a miner's best interests to broadcast it to as many nodes in the network as possible.

If it is broadcasted based on the location of miners, then won't all the miners in the pool have an intrinsic advantage of their pool peers validating the solution?

There are two kinds of miners in a pool - large scale mining operations with mining farms occupying the same physical space, and smaller scale miners who have anywhere from 1 to a few thousand miners who connect to the pools from anywhere around the world.
These mining devices receive work instructions, usually via a protocol such as stratum - once any device in the entire pool discovers a solution, the pool immediately instructs all devices connect to it to mine on top of this new block. Miners that are a part of that pool will then begin mining the next block, likely even before most other pools have finished receiving and validating the newly found block.
Since sharing your block with as many other nodes as possible is key to its acceptance in the event of a competing block, there are special solutions solely dedicated to broadcasting blocks, such as https://bitcoinfibre.org/.

Let's take a case when there are two solutions being broadcasted at the same time, one from the USA and another from China. Since, a lot of miners are there in China, Mongolia, Russia etc. doesn't miners in China have a better chance of getting consensus?

Pools will generally mine on top of the first block they see. However, consensus will only be achieved when a new block is found on top of one of the two competing blocks.

Also, what do we mean by consensus in the above case? Let's say the USA solution reached 20% of the active miners and the Chinese solution reached 80% of the miners. As per my understanding even the USA solution could reach more than 51% consensus(more than 10% of globally active miners agreeing with the solution). Shouldn't there be a threshold on the minimum number of global miners agreeing with your solution given this large pools existence?

Consensus here is not dependent on how many nodes you are able to broadcast your solution to, but depends on the next block to be mined. If block N has N_USA and N_CHINA, and block N+1 refers to N_USA as the previous block, block N_CHINA will be discarded as block N_USA is part of the longest chain, regardless of how many nodes had received N_CHINA before N_USA. Until block N+1 is found, both blocks are valid.
This is known as selecting the longest chain, or more formally, the chain with the most work.


Hacking Question: Hiring a developer to run bitcoin core to process bitcoin payments on site Hacking Question: First of all i am totally noob. I dont know much about bitcoins. I have an ecommerce website. I want to accept bitcoin payments for my products. I dont want to use 3rd party api's. I am hiring a developer to run bitcoin core on my server for my website to accept and process bitcoin payments.

Is it safe to use a freelance developer?
He'll have access to private keys?
Will he be able to hack it?
Is there a way to make my bitcoins safe from hacking in which insider job is involved?

Please kindly give me a serious, detailed and non technical answer

If you want to accept and hold bitcoins it is trivial to generate a large number of addresses offline and feed the public addresses (not the private keys) to the web developer.  He would not have any access to the funds.  Also as suggested in the comments you could use an HD wallet and provide the XPUB key to the developer.  This would allow him to generate only the addresses that you have private keys for.

For example the electrum wallet is an HD wallet that would provide the required capabilities.


Given a Bitcoin transaction as JSON data, how can I determine the number of confirmations? According to blockchain.info, 4,198 confirmations have been received on the following Bitcoin transaction at the time of this writing. Give then following Bitcoin transaction as JSON (ref: transaction on blockhain.info as JSON) how can I determine the number of confirmations?

Transaction as JSON

{
   "ver":1,
   "inputs":[
      {
         "sequence":4294967295,
         "witness":"",
         "prev_out":{
            "spent":true,
            "spending_outpoints":[
               {
                  "tx_index":0,
                  "n":0
               }
            ],
            "tx_index":0,
            "type":0,
            "addr":"1BiYTVfoAWpEf5vTCVyWgWzsbdTbi3X4Lb",
            "value":4371338,
            "n":1,
            "script":"76a914758c92328cb8f0d5a9e2bc6a1b27b6fdf83fa86588ac"
         },
         "script":"483045022100f6d8e0e386079721dc286d25c88c5cddd8733ee3d93247f3ff0127e8aa7dcb9a02206ce2b7e524e4796e93688442dcc95bb7c8e2bcf3a46ac660633fac3e0becfd5e012102a9dba5ef4653f48190bf6b12130f001fe14cda8b8e2e06bf2e96b9cf3c442503"
      }
   ],
   "weight":760,
   "block_height":615893,
   "relayed_by":"0.0.0.0",
   "out":[
      {
         "spent":true,
         "spending_outpoints":[
            {
               "tx_index":0,
               "n":0
            }
         ],
         "tx_index":0,
         "type":0,
         "addr":"3BMEXDcDGPjGGR6MHiFiHRPfz6LeGeYYM3",
         "value":4366812,
         "n":0,
         "script":"a91469f3746a2b4246695de6ae4fd0d2c27221b1cd9d87"
      }
   ],
   "lock_time":0,
   "size":190,
   "block_index":0,
   "time":1580790109,
   "tx_index":0,
   "vin_sz":1,
   "hash":"406fe52a8cb99cfdc3ed6cc3e2ef461608e369943a9c1f4132421d3de425e66c",
   "vout_sz":1
}

Confirmations are nothing but just the number of blocks added after the block the transaction was added in. So accordingly, during the time of writing, the current block is 620093 and your transaction was added in block 615893

So if you subtract these two , current block - tx added block(620093 - 615893 = 4200), you will get the total number of confiramtions, which is near to your block confirmations (4198)

Hope this was helpful. Have a great day!


Help locating bottleneck on new mining rig I built a mining rig with 3 Radeon 6850 GPUs.  When I run one miner (either Phoenix or m0mchil's poclbm) it reports a hash rate of a little over 200 Mhash/sec.  When I fire up a second miner pointed at a different GPU, the hash rate of both miners is about half what the one running alone would get. When I fire up a third pointed at the last GPU, all three miners report an even lower hash rate, such that the total is around the 200 Mhash/sec that a solo miner would get.

Initially, I thought that the miners were ignoring the DEVICE=# argument and all using the same GPU. I posted a question seeking help in figuring out why they would do that. @Lodewijk's answer there clued me in to the fact that the miners are using separate GPUs and that there's a bottleneck elsewhere in the system.

So, my question is, what's the likely bottleneck?

I used the recommendations at the bitcoin.it wiki entry on Mining Rigs to pick out my hardware.  I'm running on a Ubuntu 11.10 system, with an msi 890FXA-GD70 motherboard, 2GB Kingston 1333MHz DDR3 Non-ECC RAM, 80GB WD IDE Drive, and a 2.8Ghz AMD Semperon 145 processor. It's on a cable Internet connection with tons of bandwidth and I'm connecting to the Arsbitcoin mining pool.

Did you check the CPU usage? You can use TOP on Ubuntu (sudo apt-get install top, if it's not default). If it's not capping out at 100% it's either the chipset or CPU bandwidth giving up. You can also check you regular memory, although I'm quite sure that isn't used in GPU mining.

Some things you can easily strike off are network and disk. Disk isn't used at all and network shouldn't cap out even on dialup.

If it is in fact chipset or CPU bandwidth you have two options:
1. Overclock. Focusing on FSB clock should improve everything. I'm quite sure you can't get a 300% increase though.
2. Build a different system. I daren't advice about this though.


Are there any miners that will always include microtransactions even when no fee is paid? There is a node that will always relay every transaction, regardless of whether its amount is acceptable and whether a fee was paid.  This node is described in the Free Transaction Relay Policy page on the Bitcoin wiki.

There are no miners listed though which will always include these transaction.

Microtransactions for amounts worth just a few cents would not be able to pay a fee and even the minimum fee causes Bitcoin to no longer be "near free", as the amount on a percentage basis can become quite high.

Are there any miners which will include these microtransactions with no fee?  Do any of them connect to the node listed in the free relay policy page, or are the IP addresses for these shown anywhere?

Yes.  All miners using the default Bitcoin Core settings will include some free transactions in their blocks based on priority.

Let's say you have a microtransaction-sized 5,000 satoshi input (about $0.01 USD presently).  According to Bitcoin Core 0.10.0's estimatepriority RPC, you currently need 59985719 priority to get a zero-fee transaction mined within 25 blocks (~4 hours).  That means you'll only have to wait until your input is about 46 years old:

satoshis * blocks per year * years / tx size > priority
5000     * 52596           * 46    / 200     > 59985719

That's because priority is computed by input amount in satoshis, times the number of blocks since it was received, divided by the number of bytes in the transaction.

I haven't heard of any miners that have free transaction policies that are more generous than the Bitcoin Core defaults.


For a redeem script to satisfy the conditions of a script what must it leave on the stack post execution? I was watching this Andreas Antonopoulos presentation on Advanced Bitcoin Scripting.
It appears from Andreas' examples that for a redeem script to satisfy the conditions of the script it needs to leave TRUE (and nothing else) on the stack after it has been executed. This was also enquired about here.
Therefore there is a VERIFY suffix such that some opcodes (e.g. EQUAL, CHECKSIG, CHECKMULTISIG) have competing opcodes (e.g. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY). Instead of leaving TRUE on the stack these VERIFY opcodes will "continue execution of the Script if the outcome of the conditional operator is TRUE" but "will not push that TRUE back to the stack, it will simply continue execution". These VERIFY opcodes can be used to ensure the execution of the redeem script leave TRUE (and nothing else) on the stack rather than say TRUE TRUE TRUE.
However, in this Bitcoin Core PR review club session Pieter Wuille stated (paraphrasing):

For CLEANSTACK you have to have a stack with a single element in it which has to be nonzero. Without CLEANSTACK a non-empty stack with multiple elements is ok as long as the top element is nonzero

I have two questions:

Presumably TRUE is equivalent to 1 and FALSE is equivalent to 0?

Any opcodes that evaluate to FALSE will result in immediate failure and termination of execution? So with non-CLEANSTACK you would never see a resulting stack of TRUE FALSE TRUE pass as FALSE would result in immediate failure and you wouldn't assess the final TRUE. However, you could see a stack of say TRUE 3 TRUE 5 and this would pass with non-CLEANSTACK. (It would fail with CLEANSTACK as CLEANSTACK must have a single element in the resulting stack).

Thanks to harding for answering this question on IRC and sanket1729 for edits.

Presumably TRUE is equivalent to 1 and FALSE is equivalent to 0?

TRUE is any non-zero value.  This is often used in scripts involving the former OP_NOPx opcodes that don't pop their values off the stack after verification, e.g. a script that can be spend by a miner after a certain height could use: <locktime> OP_CLTV ; if CLTV fails, the transaction is invalid; if it passes, then the non-zero  value left on the stack allows the script to pass.

Any opcodes that evaluate to FALSE will result in immediate failure and termination of execution? So with non-CLEANSTACK you would never see a resulting stack of TRUE FALSE TRUE pass as FALSE would result in immediate failure and you wouldn't assess the final TRUE. However, you could see a stack of say TRUE 3 TRUE 5 and this would pass with non-CLEANSTACK. (It would fail with CLEANSTACK as CLEANSTACK must have a single element in the resulting stack).

All that matters without CLEANSTACK is the top value on the stack at the end of execution.  Anything further down the stack doesn't matter.
CLEANSTACK is a standardness rule for P2SH but it is a consensus rule for Segwit v0 (BIP141 specification) and Tapscript, SegWit v1 (BIP342 specification, rule 4, ii)
The word "failure" is ambiguous here. There are different ways different opcodes can fail. For example, if OP_CHECKSIG fails it just pushes a 0 to the stack. But if OP_CHECKSIGVERIFY fails, the whole script fails. You can put TRUE FALSE FALSE on the stack using just OP_0 OP_0 OP_1.
Some of the VERIFY opcodes e.g. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY terminate immediately on failure but their non-VERIFY equivalents don't.
All that matters is the state of the stack at the end of script evaluation.  For example, you could do OP_CHECKSIG followed by OP_IF OP_PUSHNUM1 OP_ELSE OP_PUSHNUM2 OP_ENDIF, e.g. if the signature succeeds, take one branch; if it fails, take another branch (This isn't considered best practice though and shouldn't generally be done.)
CLEANSTACK is an attempt to prevent malleability by having people put a bunch of junk in your scriptSig or witness data. Because you can just push a bunch of data onto the stack that never gets used and doesn't prevent the script from evaluating correctly. (Pre-segwit, this affected txid malleability and was enforced as a standardness policy rule; with segwit, this is no longer possible as it is a consensus rule)


How to Send BTC from my address to another using private key I am working on project of ICO where i am generating dynamic address for Bitcoin receive purpose, I have private key for my account how i can send it to other address which API will be helpful to me.

I am not using any bitcoin wallet, I don't think wallet is required for this.

  I am not sure about this, can anyone guide me on this. I am a new to
  bitcoin.

If you don't want to use any wallet software, you could install bitcoind on your local host and

https://stackoverflow.com/questions/38493893/heres-how-to-send-raw-transaction-btc-using-bitcoin-cli-command

You could use an online version of bitcoind RPC endpoint, but I am not sure you want to submit your private key over the network.


How to check Bitcoin wallet balance without any API I am building an application and that will involve large set of bitcoin wallets and need to keep on checking for balance. I don't want to use any third party APIs as they all have hourly/secondly limits.

Is there any way I can check bitcoin wallets balance without any API? I am not sure is Bitcoin Demon and Bitcoin Core is for this purpose. Can anyone please suggest me the best way to verify bitcoin balances and transactions without any limits.

If you are not going to use a 3rd party API, you'll need to run a node and add each address you want to query as a watch only address. If you are looking to create a database with all addresses, similar to a block explorer website, you'll need to parse the blockchain using something like abe, and then continually update your database for each new transaction.  There's also the painful approach of turning on txindex=1 in your bitcoin.conf, and then going through every single block since genesis, that checks all txs outputs and then keeps a record of all addresses and transactions.


Why the blockchain isn't just a Merkle tree I am reading this and now wondering why the blockchain isn't just implemented as a Merkle tree, or the reverse, why you can't just have a single data structure (i.e. a transaction chain) instead of the block chain with nested Merkle tree of transactions.

A bitcoin full node independently validates the history of the network. To do so, it must validate each block in sequence (which includes all transactions in each block).

A merkle tree provides a cryptographic commitment to some data, but does not hold that data itself (it just holds hashes of the data). So a merkle tree alone is insufficient to validate the history of the network. Nodes need block and transaction data to do so, not just the merkle tree commitment.


Whats the difference between "txid" and "hash" - getrawtransaction bitcoind Sometimes the txid key is the same as the hash key in the return of getrawtransaction, sometimes different. I'm trying to understand more about these...

What are the differences, and why are they sometimes identical and sometimes different?

Example - identical in this testnet tx:

bitcoin-cli -testnet getrawtransaction c3f11d1708ac20eff9137d4eadd62dd99d71ce22dc51bc51d4e5b83958d9596d 1

Example - different in this livenet tx:

bitcoin-cli getrawtransaction df2fd78e42590f301b5174e7d6665887380ad1f49a4688a0f8adffa0829855cc 1

Summary: The difference is when the tx is a segwit tx, the calculation of hash does not include the witness data, whereas the txid does.

The definition of transaction hash remains the same as txid for non-witness transactions (non Segwit). The reason the mainnet tx has a different hash than the txid is because it is a witness transaction. If you run bitcoin-cli help getrawtransaction it will show you:

Result (if verbose is set to true):
{
  ...
  "txid" : "id",        (string) The transaction id (same as provided)
  "hash" : "id",        (string) The transaction hash (differs from txid for witness transactions)
  ...

Segregated Witness

The following is from BIP 141.

Note that the BIP states, "signature data is no longer part of the transaction hash."

Transaction ID

A new data structure, witness, is defined. Each transaction will have 2 IDs.

Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:

[nVersion][txins][txouts][nLockTime]

A new wtxid is defined: the double SHA256 of the new serialization with witness data:

[nVersion][marker][flag][txins][txouts][witness][nLockTime]

Format of nVersion, txins, txouts, and nLockTime are same as traditional serialization.

The marker MUST be a 1-byte zero value: 0x00.

The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.

The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script.

A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.


Why would Mt. Gox's Open Transaction method still require six confirmations? When withdrawing using Mt. Gox, one of the checkboxes is marked "Open Transaction" and it shows that this requires "6 Confirmations".

This is used if you might be paying another Mt. Gox account but want it to go through the blockchain rather than as a transaction handled internally by Mt. Gox and thus no corresponding transaction in the blockchain is made.

Since the input for the transaction is coming from Mt. Gox's own wallet, there is no concern over double spending.  Why would Mt. Gox require six confirmations for these if the recipient is another Mt. Gox account?

I think it's as simple as MtGox waiting for 6 confirmations before accepting bitcoin deposits to your deposit address, no matter where they've come from.

If you want instant transfers, don't use "open transactions".

We can try to make up reasons to try to make this policy make sense, but ultimately they make the rules and we act accordingly.


Are bitcoin commands resistant to race conditions and thread-safe? Is concurrency a problem for commands like sendfrom,move,sendmany etc.? I suppose everything is fine after skimming source code, but I want to be sure about that.

Yes. All these transactions do is create a new transaction (or move entry) in the wallet. Balances are always calculated on the fly (though partially cached) from the transaction list.


Bitcoin/US Dollar Exchange Rates If Bitcoin were to be used as an alternative, industry-specific banking platform, what would the effect of all 21M bitcoins in circulation be on the dollar/bitcoin exchange rate? Or, would it be better to create some kind of new digital currency specific to that industry while simultaneously creating an exchange for that currency?

It is notoriously hard to establish a digital currency derived from Bitcoin that focuses on a specific niche. This has for example been attempted with country specific currencies (e.g. Auroracoin in Iceland,  MazaCoin for the Lakota nation and SpainCoin in Spain, see national altcoins), and industry specific coins (e.g. MaryJanecoin, Titcoin, and PotCoin).

The main issue is that Bitcoin and other more popular altcoins have a much better utility due to broader acceptance, and the newly created coins often immediately get sold for those after an initial hype.

Specifically regarding Banking, banks actually have very different needs than what Bitcoin provides: Their environment is more one of cooperation with known particpants, where a central database would be more of a communication and audit tool rather than one to achieve consensus. This has both allowed Ripple to successfully pursue banking clients with their IOU based network, and has led to a score of banks founding the R3CEV, whose product naturally diverged significantly from Bitcoin's blockchain.

I could see how the banking industry would attempt to resist the adoption of an open blockchain by favoring such a permissioned blockchain. The latter are naturally much more efficient as the decentralization comes at the cost of inefficiency. Unless an open blockchain overwhelms other forms of money, I would expect both to survive.


How to send BTC amount from one specific address in Bitcoin Core I canceled one transaction that was in the memory pool, now I would like to make sure that this transaction will not be sent anymore sending all BTC amount of the original address of this transaction to another address, but when I go to send BTC in Bitcoin Core, I can't choose one specific address to send the amount. So what Can I do to "empty" the bitcoins of this address using Bitcoin Core?

If you run Core with the command line flag -zapwallettxes it will forget transactions in its mempool.


How to get historical balance of a Bitcoin address at a particular block number or date? I would like to get the balance of a Bitcoin address at a particular block number or date.

Is there any way to retrieve this data from JSON-RPC? Alternatively, is there any API or blockchain analytics service that provides this? Thanks.

Account/address balance are higher level constructs that are built on Bitcoin's low-level transaction scripting language and cryptography. As such, data related to funds 'belonging' to a particular address is not readily available in the blockchain, but has to be built separately by scanning the entire database. The Bitcoin-Core reference client does not even support showing 'balances' of address that are not part of your wallet, let alone providing you the data related to a particular address at a particular point in time. You would either have to do this yourself or search for third-party data providers who provide this kind of information through an API (that is off-topic on this forum).


How to generate new wallet address per token I'm using getnewaddress bitcoin-cli function to generate wallet addresses but i need one address per token.
Is it possible to use a parameter like seed for random numbers to get the same address when i use the same token?

I finally found a solution. here is the function to get tone address per token:
try:
    addressjson=gateway.getaddressesbylabel(token)
    address=list(addressjson.keys())[0]
except:
    address=gateway.getnewaddress(token)
return address

this way if an address assiciated to the label: token exists we use. Otherwise we generate a new address with label token.


To create a blockchain using MySQL database I want to create local blockchain for my application. New blocks should be created while giving reference to previous block. But I am not getting exactly how will I do it in MySQL? I got some idea from http://blog.theodorejb.me/sql-linked-lists/
. Now I want to retrieve top block every time I create a new block. But Is it possible in MySQL to retrieve Newly inserted row's primary key? Or Is is possible to implement stack(with reference) in MySQL ? So that I can retrieve top block.

I believe you are over complicating your life.

Having a BlockChain (a Linked Ledger) in SQL can be prototyped in the following manner

Create a table, such as:

CREATE TABLE IF NOT EXISTS
MyBlockChain (
    LedgerID int(10) NOT NULL auto_increment,
    block varchar(255),
    datetimestamp datetime,
    guid varchar(255),   --Have a Default GUID Generated
    PRIMARY KEY( `LedgerID` )
);

Having an AutoGenerated Sequence Number (as a primary key) - This creates the sequence in your ledger.
Assign Proper Security to only allow INSERTS to happen over a Public API.
Only the GUID is used to access a Record (block) via ReadOnly permissions.
When users can only INSERT Data (No DELETE or UPDATE) you, in essence, created a Ledger.
And since the Sequence Number will be used to determine ordering of actions.

The biggest challenge to distributing the MySQL database over multiple instances an having an API interface and ensuring ReadOnly and Insert Only security.

That by default is a simple implementation of a BlockChain


How does Bitpay.com getting transactions info as its open source? How does Bitpay.com wallet getting transactions info and listing unspents?

Are they connecting to Electrum servers peers or are they connecting to their servers?

You can check your transaction's confirmation status and other payment details on any blockchain explorer (like BitPay's block explorer Insight). Look up your transaction using your transaction ID or the sending or receiving bitcoin addresses, which can all be found in your bitcoin wallet that sent the payment. For your transaction to be considered fully confirmed by most BitPay merchants, your transaction will need to have six confirmations.

More info: https://insight.bitpay.com/


Recipient calculation in verifyTransactionBytes for Ardor I'm trying to add verifyTransactionBytes to my app.  I am currently stuck because of transaction.recipient !== data.recipient.  I don't understand how transaction.recipient will ever equal data.recipient.

data.recipient equals ARDOR-64L4-C4H9-Z9PU-9YKDT

However,  transaction.recipient equals 12686039152117651770352583052021228896653772998482022211948610002430512793010043372255281183988421160450227631016638876582933743874739812608892576232835541561180017189881475915550182092483428449468438018195304514943626747005224233901130236596723251118266281272406204049816147466250586545776300564249483796886483621200942491492199171631589798205980673

This doesn't really surprise me, because I don't see how an ARDOR address gets generated from transaction.recipient = String(helpers.byteArrayToBigInteger(byteArray, pos));

Which looks like it should return a number, not a string.  What am I missing

You need to either convert data.recipient from RS format to numeric format or convert transaction.recipient from numeric format to RS format using NRS.convertNumericToRSAccountFormat(id)


What is the difference between the txsize in mempool and mempool dynamic usage? There is a table for the txsize in mempool and dynamic memory usage of mempool on statoshi.info's mempool overview?
The default size of mempool defined in Bitcoin is 300MB, so is this default size the total txsize or the dynamic memory usage?

It looks like Mempool Transactions (the top graph) gives the total raw byte size of the serialized transaction data in mebibytes (1 MiB = 1024² bytes). Note that this is not equivalent to transaction weight (1 MvB = 1000² vbytes)—the transaction weight of the mempool is currently ~102.9 MvB, but this graph shows 96.1 MiB.
A node's mempool limit pertains to the dynamic memory usage of the deserialized transactions which for the 96.1 MiB of serialized data and 102.9 MvB of transaction weight is currently just shy of the 300 MiB limit with 286 MiB.
You may also find What if the mempool exceeds 300 MB? interesting.


What exactly happens when a new wallet is created? I am asking for what is being created when there is a new wallet created.

And the second part of my question is considering public key. Is the public key the same thing as the address? I read that there is for every private key a large pool of 100 adresses. Every adress is used when sending any single transaction and "creating" new adress.

Your wallet is a collection of private keys and a record of the transactions relating to them.  By default your wallet has a key pool of 100 keys.  So when your wallet is created, around 100 private keys are randomly generated and stored in your wallet.

Each private key has a corresponding public key, and each public key has a corresponding address.  A public key isn't "the same thing as" an address, but there is an algorithm that can give you the address corresponding to any given public key.  The reverse isn't true.  There are many different public keys for each address, since public keys are 256 bits wide and addresses are only 160 bits wide.

When you click 'new address' in the 'receive coins' tab of the client, it will show you an address you've not seen before.  It is taken from the 100 address keypool.  The keypool is topped up when possible to always contain 100 unseen addresses.  If your wallet is encrypted then it's not possible to top up the keypool until the wallet is unlocked with the passphrase.

Also, when you make a transaction out of your wallet, it's quite likely that the amount you are sending doesn't exactly match the sum of any of the inputs you currently have private keys for, and so some 'change' needs to be sent back to your wallet.  When this happens an address from your 100 address keypool is used to receive the change.  In this case the keypool will be immediately topped up, since your wallet will need to be unlocked since you're spending coins.

This all happens behind the scenes - you won't see any evidence of it happening unless you look at the blockchain.


What states is Kraken doing business in Is there a list of states that the kraken exchange is currently doing business in?

Kraken also known as Payward Ventures Inc is currently registered as a Money Service Business in every single state in the US.

As far as I can tell however they will still not do business for the 2nd 3rd or 4th tier verifications in any state. I have no idea why this is.


how can i get data from GDAX Bitfinex using API and show like bottom how can i get and show below link data, can someone please help me

https://runcoders.com/live-bitcoin/

i am trying by this but failed to show like up link

<?php
//define API endpoint
$url = "https://api.gdax.com/products/BTC-USD/stats";

//fetch the url and convert the JSON into an associative array
$fgc = json_decode(file_get_contents($url), true);

//assign values to variables
$open = $fgc["open"];
$high = $fgc["high"];
$low = $fgc["low"];
$close = $fgc["close"];
?>

My Website

Bitcoin 24 HR stats

Open: $<?php echo $open; ?>

High: $<?php echo $high; ?>

Low: $<?php echo $low; ?>

Close: $<?php echo $close; ?>

They are just using websocket to connect to the exchange and then outputting the lives trades to the page by appending it to an element.

Here's a simple example using bitfinex:


If I lose a Trezor then how does the replacement get access to the same wallet? I am pretty confused.  What I understand is that when I buy a Trezor then it gives me some words that I need to copy down.  When the Trezor starts up does it then automatically create some Bitcoin addresses and keys?

If I lose my Trezor, then how does a replacement know about my previously created Bitcoin addresses and keys?

Trezor implements BIP32/BIP39 (hierarchical deterministic wallet and mnemonic encoded seeds, respectively).

The mnemonic (12 words) is just a way of encoding a hex seed like 6c5f9d00018f2a2030afcc6f3057e5a4dea6dfb905dd4b0197a9a047bcfe0501662332a3caa846b1223ff3d20cfb295e7f94fe51c94472e3f8429c97754132e9 (whose mnemonic would be business weird season glimpse pole robot surprise next term toddler doctor fresh). The hex seed is then used for a master private key and a master public key pair (in this example, xprv9s21ZrQH143K29DbrSg2YgC2iyW3Gx3FhNExbxEacDWJCmz9xmsxKjon93FSC85Bv4AkszKLK1d3FA6PKS1Wb6xYotbDppezTMQaazbPL6h and xpub661MyMwAqRbcEdJ4xUD2up8mH1LXgQm74bAZQLeCAZ3H5aKJWKCCsY8FzL33Ay3XxoX7xWyq4pejzuSQEQw2hA2CvWvKBgMGTJLgZXRzdbf, respectively).

So if we look at this bip39 tool, the mnemonic business weird season glimpse pole robot surprise next term toddler doctor fresh has a list of addresses which will be used by the Trezor, in order (in this example, the first listed address begins with 18SKy...).

All of this is just demonstrating how it works (do not enter your mnemonic into a website as this example shows!), or as TL;DR: the mnemonic is all you need to recover the keys for Trezor addresses


How exactly are public/private keys stored? So Bitcoin uses an HD wallet and thanks to that it can store keys in a hierarchy. But how exactly and in what format are they stored? Is each private and public key stored as a separate file? Are they stored in textual or binary format? Does Bitcoin use a database to store them?

The only resource I found is the source code of Bitcoin Core but are there any books or sites where I can find explanations about this?

No they are not stored, the child keys are calculated from the master when needed as they are deterministic, not random.

Here are some references:

https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html#_deterministic_seeded_wallets

https://learnmeabitcoin.com/guide/hd-wallets


Check if received bitcoin are in blockchain/not pending without a transaction id I want to use the Bitstamp exchanger API to buy Bitcoin automatically. But then I see the API does not give me back a transaction-ID (txn id) if I do a withdrawal of Bitcoin to my wallet.

If the exchanger gives me no transaction-ID when I start a withdrawal, how can I check that everything is fine? Normally, I think, you wait for x confirmations of the transaction, but the exchanger won't provide it.

Is it enough to check the receipt of the Bitcoin amount in a unique account or will I be assailable for transaction malleability, double spending or similar? Is there a reason why the exchanger doesn't give back a txn-id? Because I saw other exchangers which do the same.

I am grateful for any advice.

It's not how all exchanges are handling this.

Bitstamp is sending bitcoins in batch transactions. That means it is sending your bitcoins to your address and other users' bitcoins to their address in the same transaction.

That means that bitstamp does not yet know the TxId when you submit your withdrawal request.

That is the why.

As for how to solve it, yes you can get a new address for each withdrawal and wait for it to get confirmations. You will not be assailable for transaction malleability, double spending or similar if you do that.


Verifying a digital signature that a transaction is going to an output with value X inside a script Edit; after writing this post i have found that OP_CHECKDATASIG is basically this in a nutshell. It is implemented on Bitcoin Cash and may soon be on Bitcoin Core as well.

Someone has even written this post into a Bitcoin Cash smart contract: https://honest.cash/pein_sama/spending-constraints-with-op_checkdatasig-172

but in bitcoin usually the message is a hash of the previous transaction and the 'to' pubkey-hash and/or transaction? Unless i am missing something, the SIGHASH_SINGLE parameter specifically signs only the input and output of the new transaction. So, if you could create this input and output, and sign it inside an OP_CODE with a privatekey, you could verify that an output was going to a particular person inside a bitcoin script sig. Of course, the private key holding that UTXO would be unusable except for returning BTC to the user, or perhaps another pubkey could be used to spend the UTXO.

This is incorrect. Transaction signing works by:

for every input i in inputs:
    Start with a transaction skeleton that matches the transaction for non-input/output fields like tx version
    Add the input i
    Add other inputs and outputs based on the sighash flag
    Hash this update tx skeleton
    Sign the hash

The SIGHASH flags simplify specify which inputs and outputs are covered by the signature. For SIGHASH_ALL, the entire input and output set is signed. For SIGHASH_SINGLE, only the output corresponding to the index of the input is signed (for the first input in a tx, the first output will be signed). You also have additional options such as ANYONE_CAN_PAY which allow addition inputs to be added later, by only signing your input (for use with coinjoins).

By using SIGHASH_ALL | SIGHASH_ANYONECANPAY or SIGHASH_SINGLE | SIGHASH_ANYONECANPAY flags, if you already control an output, you can specify something such as:

If this output is used as an input, at least X BTC must be sent to {these|this} new output(s).

However, this restriction only applies if the final transaction uses this specific signed input - nothing prevents you from creating another signed tx that spends that same output to a different destination and broadcasting it first.

Your example fails since within the signature, you have no information about the output. The data that is signed is that of an augmented tx skeleton as a whole - you cannot use Bitcoin Script to inspect a subset of that data and validate the signature.

To take the example another way, let us say we construct a bitcoin script equivalent to:

Accept a signature and a public key
Verify that the signature is over the data (input,hash160(public_key)
Verify the signature is performed by the same key that unlocks the input being spent

This would seem to imply that we can sign the destination public key using the same private key that owns the input, and then have a script that validates both the tx signature, and the signature over the public key we claim to send to.

However, in this case, nothing prevents you from feeding a valid signature and destination public key to the script, but specifying a completely different output in the actual tx - This is because there is simply no way for the Bitcoin Script program to read and check where the tx output(s) are actually going.


Exchanging BTC (bitcoin) for LTC (litecoin) How can I safely exchange BTC for LTC? I've found a website called Changelly. Does anyone have any experience with this website? Are there other websites/ways to safely exchange cryptocurrency?

I want to make sure that if send BTC to a specific person, then they'll send me the corresponding amount of LTC.

Just use shapeshifter!

https://shapeshift.io/

No account needed, instant, and it has a fair exchange rate. I used it multiple times to exchange coins.


Is a private blockchain better in any sense than a database? Since the banks appear to be currently looking into the idea of "blockchains" but don't want to be dealing with "Bitcoin", it seems that there is a lot of hype for private blockchains out there like Eris or Hyperledger. However, a lot of people tend to point out that a blockchain without a currency is essentially "an SQL database".

I'm wondering, does a private blockchain have any advantages over a traditional database solution, or can everything that a private blockchain does be replicated with some effort using a database application?

It depends on what you mean by "private". The word private is not really associated with Eris as far as I can tell. Rather, the word "permissioned" is used instead, and therein lies all the difference and your answer.

A "private" blockchain might imply a blockchain that is not shared with anyone. Such blockchains would effectively amount to slow databases and nobody would have much need for them.

Eris' value proposition over traditional databases is simple: integrity through cryptographically signed history.

What's stopping twitter from editing my tweets and making it seem like I said something I didn't say? Little to nothing.

This is where a blockchain approach comes in. If twitter stored tweets in a blockchain that others could copy, then any modifications that twitter made to this chain would be caught.

Blockchains preserve the integrity of the data within a database. They prevent people from cooking the books. This is of extraordinary importance and value.

Comparison to git

Git does not have a smart contracts system within its protocol.
Git is more of a filesystem interface, whereas Eris seems more like a database interface, to be used in environments where databases are sometimes used. Git is rarely used like a database.


Send a transaction using bitcoinjs-lib to testnet in a box I put together some code using bitcoinjs-lib which allows me to create a testnet transaction and send some bitcoins from one address to another.

But I'm getting tired of waiting for 10 mins after every test. I'd like to be able to test my code a bit faster.

I set up testnet-in-a-box in a virtual machine and have played around with a few commands and it works fine.

But when I try to send a transaction to one of the nodes at 127.0.0.1:19000 it gives me an error saying:

{ [Error: socket hang up] code: 'ECONNRESET' }

I'm broadcasting the transaction as shown here using:

blockchain.t.transactions.propagate(tx.build().toHex(), done)

What am I doing wrong? Is it not possible to submit transactions to the node in testnet-in-a-box?

Any help will be appreciated! Thanks!

The propagate function isn't designed for testnet-in-a-box because there is no routing for requests in the bitoind program that testnet-in-a-box activates.
Rather testnet-in-a-box is designed for JSON-RPC, so you can use sendrawtransaction, which described in https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list.

This is the propagate function:

blockchain.transactions.propagate = function broadcast (txHex, callback) {
  dhttp({
    method: 'POST',
    url: 'https://api.ei8ht.com.au:9443/3/pushtx',
    body: txHex
  }, callback)
}


I noticed that sending a transaction actually means sending your entire wallet amount to the person and you get change back? I just noticed that when you send an amount to someone. You actually send them the entire wallet amount and then it gets sent back as change. Is this true and why was it implemented in this way?

Also since it gets sent back as change, how would this affect a paper wallet? Does the same apply? Currently I have a paper wallet and I sent some coins to another wallet from my paper one. I hope everything is still safe.

Requiring an output to be fully consumed by a single transaction simplifies things -- an output is either spent or unspent, period. The idea is to avoid a proliferation of partially unspent outputs that would be very difficult to track. If a transaction could partially consume an output, then you'd have a whole new category of partially unspent outputs, each potentially partially consumed in some number of places.

It is possible to send the "change" to the original receiving address. If you do that, the paper wallet will still contain the key to access the new change outputs. If you use a new address for the change, then the paper wallet will be unable to spend the change. (Unless it's a complex type of deterministic wallet, which I very much doubt.)

With the current system, each output is either consumed by a transaction which has it as an input or it is unconsumed and is a valid output to be consumed by a future transaction. With partial spends allowed, each output could be partially-consumed by any number of other transactions, making the system much more complex.

Current System:

You get a check for $100. You now have a $100 unspent output.
You send $10 to a friend by consuming the $100 and sending $90 to yourself. The $100 check is now fully consumed. You have one output for $90 and nobody cares about the check anymore.
You send $20 to a friend by consuming the $90 and sending $70 to yourself. You now still have only one output, both previous outputs are fully consumed.

Notice how the state stays simple at all times? Every output is either fully-consumed or untouched.

System with partial consumption:

You get a check for $100. You have a $100 unspent output.
You send $10 to a friend. To understand that you have $90 left, we need to look at both the $100 check you got and the $10 you sent to a friend.
You send $20 to a friend. To understand that you have $70 left, we need to look at the $100 check you got, the $10 you sent in step 2, and the $20 you sent now.

Notice how the system's state is getting much more complicated? To understand what is left of the $100, we have to look at two other transactions that partially consumed it.

It's just much simpler to fully consume and replace with a new, smaller unspent output than have to track partial consumption across two places.

Worse, imagine if you got two checks for $10 and wanted to send $15 to a friend. Now we'd have to look in three places to know what was left -- both checks and the $15 you sent to a friend to figure out you have $5 left. It's much, much simpler to just destroy the original checks and issue you a $5 payment to yourself. Now, we know the checks are dead because a transaction touches them. We know the $5 payment to yourself is good because nothing touches it. Everything is either spent or unspent. Simple.


Is there an active testnet for Bitcoin Cash? To learn more about Bitcoin Cash, I would like to try some things on the testnet.  I installed bitcoin-abc, made a copy of an existing datadir from a Bitcoin Core testnet install, and ran bitcoin-abc -testnet -reindex.  It got as far as:

2017-08-08 15:54:14 UpdateTip: new best=00000000f17c850672894b9a75b63a1e72830bbd5f4c8889b5c1a80e7faef138 height=1155875 version=0x20000000 log2_work=69.338231 tx=14689192 date='2017-08-01 13:58:35' progress=0.993792 cache=154.7MiB(460629tx)
2017-08-08 15:54:14 ERROR: AcceptBlock: bad-txn-replay, non playable transaction (code 16) (block 00000000000005063e35114c186ffd196272310fbe8265012ba0151eef092430)
2017-08-08 15:54:14 Misbehaving: 80.100.203.151:18333 peer=1 (0 -> 10) reason: bad-txn-replay
2017-08-08 15:54:14 ERROR: ProcessNewBlock: AcceptBlock FAILED

I presume this is where the fork happened.  However, the client does not seem to be receiving any further blocks beyond this point.  It seems that many peers are being rejected as "misbehaving", presumably because they are really BTC nodes on the other branch of the fork.  (Though there are a lot of receive version message entries in the log that are not followed by Misbehaving.)

Are active transactions and mining taking place on the Bitcoin Cash testnet?  If so, how can I connect to nodes that know about it?  If not, why not?

Yes, there is.  After many hours I eventually received blocks up to the present time.

There is a working DNS seed at testnet-seed-abc.bitcoinforks.org (hardcoded in the Bitcoin ABC source) which lists active Bitcoin Cash testnet nodes, many of which actually work.  Bitcoin ABC doesn't seem to prefer this seed - it tries lots of others that only have Bitcoin Core testnet nodes - but you can do manually do dig testnet-seed-abc.bitcoinforks.org and then addnode the resulting IP addresses.


is there a Java or C# library for mining bitcoins? Hi guys is there a Java or C# library for mining bitcoins? I am hoping to incorporate it into an application. I have read the other questions that asked about libraries but i need to know if these libraries allow mining

Diablo Miner is GPU miner implemented in Java. It's not a library, but it shouldn't be hard to incorporate it's code in another application.


Why can the race between the honest chain and an attacker chain be characterized as a Binomial Random Walk? I am not familiar with Bitcoin, hope someone can tell me why. Thank you!
Let's consider the following scenario.
The probability of the attacker finds the next block is q and the probability of the honest node finds the next block is p.
Suppose the attacker and the honest node began to find the next block in the meantime (so they spend the same time on finding the PoW solution). If now the attacker finds the next block, since the attacker will not broadcast the block, it won't affect the honest node. The honest node will continue to work on its own PoW. So maybe the probability of the honest node finds the next block is larger than p now (Because the honest node now will spend more time than the attacker on finding the solution of the next block's PoW).
Why can Satoshi consider this catch-up process as the gambler game? Is this just a simplified math model? Or is there any procedure I don't know such that once one node finds the next block, all miners will restart their mining work?

Great question.
So the general gist of 'random walk' is contingent on two different things:

Probability

Logic

It's better to start with the logic part because it will make the probability portion more logical.
Looking at the Logic
From the Bitcoin whitepaper, Satoshi states:

"The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failiure event is the attacker's chain being extended by one block, reducing the gap by -1."

"The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven."

Breaking This Down
If we were to consider a miner to be an "attacker" then that means that they must have "reversed" a transaction they spent in order to spend it elsewhere (maybe to a wallet they own).
Using this principle, we know that the transaction must be in the past.
So if we're mining at block height 'n', then at best, the attacker must start at n-1 (since they need to reverse a transaction that already was mined in a block).
Here's Where Probability Comes in
As that miner attempts to catch up to the network, they're already at an inherent disadvantage since they're a block behind.
Assuming the network solves for 'n' before the attacker solves 'n-1', then their chances of then solving 'n-1', 'n', then ultimately solving 'n+1' (the new block that the network is working on) decreases substantially.
With this decreased possibility of catching up, the network's probability of extending the lead then increases.
Formula
Not sure if this suffices, but Satoshi included both a formula and C code in the original whitepaper.
The formula is as follows:

The C code is as follows:

#include "math.h"
#include "stdio.h"

double AttackerSuccessProbability(double q, int z)
{
 double p = 1.0 - q;
 double lambda = z * (q / p);
 double sum = 1.0;
 int i;
 int k;
 for (k = 0; k <= z; k++)
 {
     double poisson = exp(-lambda);

     for (i = 1; i <= k; i++)
     poisson *= lambda / i;
     sum -= poisson * (1 - pow(q / p, z - k));
 }
 return sum;
}

int main()
{
double ans = AttackerSuccessProbability(0.1, 1);
printf("'%f'", ans);
}

Hopefully this explanation thus far makes sense (and you find the answer to your question to be adequate)


Time allowed to a node to react to verify a transaction and number of verifications? Do the person acting as full nodes have to be active and online around for a particular decided time, like a job where you have to be around your machine because a transaction for verification can pop up anytime and if you are not around what happens then?
Also, the Bitcoin has more than 30000 nodes, how many verifications it actually need to become a part of ledger because how can you guarantee that this number of people will verify it in this fixed amount of time otherwise the wait could go indefinite?

You seem to misunderstand how transaction validation and finality works.
Nodes validate transactions as they receive them in the mempool or in new blocks - these validations check for standardness (for mempool txs), and consensus compliance  (ensuring there are no double spends, valid utxos, etc).
However, a transaction is not final simply because a number of nodes have confirmed it. A transaction is final ONLY if a miner includes it in a block AND that block is accepted as valid by the network. This finality happens regardless of whether there is 1 node on the network, or 30000.
Note that even after being mined into a block, conventional wisdom says to wait for new blocks to be mined on top of that block, to provide a reasonable guarantee against minor forks rolling back a transaction you consider final. Most exchanges and service providers wait for 2-6 confirmations before considering a transaction truly final.


What is the rationale for inclusion of previous amount in SegWit signing process? When spending a P2PKH output, the "data" we hash only includes the output script from previous transaction but when spending a P2WPKH (the new serialization) we also include the amount field from previous transaction (#6 in BIP-143 specification). Why?

It's not particularly required and may be considered redundant as that information is generally implied from the transaction outpoints referenced in the input. However, this form of transaction serialization allows wallet softwares to explicitly commit to the fees involved in the transaction. This is particularly useful if say you are using a hardware wallet where you have your private keys and at the same time you use a watch-only online wallet. Since the online wallets knows all the UTXOs that your private keys control, it can effectively create a transaction consuming some inputs.

To know how much fee you are committing to the transaction, the hardware wallet would have to query the input referenced, grab all the outputs of that transactions (which may be very large) and then only it will know what the fee is for this particular transaction. Otherwise, if it doesn't, the software that created the transaction could lie, and in fact convert a giant portion of the bitcoins consumed into fee without you knowing it. However, keeping the input amount as part of the message that signature commits to means the hardware wallet software knows the amount explicitly and hence can provide the user with an accurate measurement of the fees.


Retrieve BCC/BCH but now have 0. Was i Hacked? hey guys i followed an instruction from reddit and exodus chat and both had similar instructions to retieve Bitcoin Cash. I followed the instructions and it seemed like i received the coins though it took hours to confirm.
I started by stransfering my BTC from Exodus to Jaxx, then use the Exodus private key to retrieve BCC with Electron Cash.
I opened it yesterday and it said i had the balance i expected. today i open it it says 0 BCC.
take a look:

I havnt sent any of my BCC to anyone. I was trying to send to my exchange when the app said "insufficient funds". Was i hacked or something?
Help!

It looks like you're not the only one who ran into this. Someone posted about this on bitcoin talk too. One user posted this is the result of a peer list poisoning bug:

  Electron Cash has a "peer list poisoning" bug, see
  https://twitter.com/ElectrumWallet/status/892433256385261568 This is
  probably what you are experiencing. To fix that, disable auto-connect,
  and select a server that you trust to be a BCC server.

Apparently the casharia server is working for people.

Also quick PSA that Electron Cash is not related to the Electrum Bitcoin SPV wallet. This is the announcement on BCC from Elecrum: https://electrum.org/bcc.txt

There's also a warning about Electron Cash from Electrum:

  The person who distributes the Electron Cash binaries has decided to
  remain anonymous, and uses the fake name "Jonald Fyookball" in order
  to sign Electron Cash binaries. Thus, if these binaries contain code
  that is designed to steal your bitcoins, the author of the theft will
  be anonymous and walk away safely with your funds.


Any privacy considerations regarding allowing inbound connections for a Tor full node? I wanted to know if there's any privacy considerations to take into account when opening the bitcoin ports on the router for a bitcoin node.

I'm using -onlynet=onion in the bitcoin.conf file and I did not modify any tor config file.

I also wonder if a remote port scan can detect I have a bitcoin port open in the router and whether changing to a random port would help privacy. thanks.

If you are running -onlynet=onion, there is no need to open any router ports. Perhaps I misunderstand your question.

If your chain state is caught up, and bitcoind+Tor is properly configured, you should be serving data to other nodes, even behind an otherwise locked-down home router.

What result do you get when running

$ bitcoin-cli getpeerinfo | grep true


Incentive for mining by regular users Most of the time that a regular user gets introduced to the concept of mining, they're immediately non-incentivized by the community and also by the high-cost of hardware compared to the actual reward.

With the steady difficulty growing and the environment around mining getting more competitive, it's pretty much a highly-specialized task where only large corporations with enough connections to buy cheap mining hardware can actually make an investment out of mining. Not the regular user.

If we fast-forward a couple of years I see this becoming more and more centralized and only few organizations will be able to actually afford mining.

My question is, how do we keep it decentralized and not resort to a situation where the power of the entire network resides only within few large corporations?

Leaving aside the question of the entry cost of mining (i.e cost of buying hardware), once you have this hardware there is actually an incentive to mine for a pool rather than to mine solo.

Indeed in both cases your expected value is the same but the variance is smaller when you mine for a pool than when you mine solo. That means that in the (infinite) long run you would theoretically earn the same amount of bitcoins in both cases but not in the same manner : in a (big) pool you would often get small fractions of bitcoins whereas solo you would mine a block very rarely but get a lot of bitcoins when you do.

So by mining solo you are relaying a lot on luck, and by mining for a pool you reduce the role of luck. Usually when people make an investment (here it would be buying hardware) they prefer to reduce the importance of luck for the returns, that's why I would say there is an incentive to mine for a large pool. And for the same reason there is an incentive for the pools the get larger : the larger the pool the smaller the variance.

However there is a counter-incentive for a pool the get more than 50% of the hashrate, because if one pool was discovered to be in such a position it could kill the confidence in Bitcoin thus killing bitcoin's value and all that mining hardware that the pool invested in could turn worthless.

So maybe the equilibrium is that there will be a few large mining pools but none will have more than 50% of the hashrate.


How are the seed nodes chosen? I'm currently doing a research project about Bitcoin and I've particularily been investigating the seed nodes and I have two questions about them :

How are they chosen ? Well, they have to be nodes with high disponibility (bandwith maybe?) but is there any other criterion ?
Why are some of the nodes located in the network of big companies ? Isn't it a bit contradictory to Bitcoin's spirit to have the ip address of some major financial companies hardcoded in its client ?

Thanks for your answers :)

Ayla

According to the Bitcoin wiki https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

  Nodes discover their own external address by various methods.
  Nodes discover their own external address by various methods.
  Nodes makes DNS request to receive IP addresses.
  Nodes can use addresses hard coded into the software.
  Nodes exchange addresses with other nodes.
  Nodes store addresses in a database and read that database on startup.
  Nodes can be provided addresses as command line arguments
  Nodes read addresses from a user provided text file on startup

Because this is peer-to-peer technology the client is usually connected to more than one node at a time. The reference client validates every bit of information it receives. If a financial company was to go rouge and send false or incomplete data the software would realise the data is invalid and rely on the other connected nodes to operate.


Can a bitcoin transaction be reversed from the receiving end? I know this seems like a duplicate of the question 'Can a bitcoin transaction be reversed?' but none of the answers there were explicit enough as they all seemed to assume reversal triggered from the sending side.

I guess a secondary part of my question is 'What would happen if a merchant just sent the funds back to any one of the input addresses that was used in the original transaction?' Would the  money be effectively returned to my control?

When sending coins, the original Bitcoin client picks the more "secure" coins, i.e. the oldest ones that can be used as input for the transaction. Internally, it doesn't care about accounts, although it does of course keep track of each account's balance.

As a result, sending coins back to an input address will only guarantee they will go back to the original wallet, not necessarily the original account, let alone the original person. In many situations wallets are shared between different persons, e.g. in web services (online wallets, mining pools, etc.), so the difference is crucial.

Thus if you're designing an application and you want to allow refund, you should absolutely not rely on the sending address in your application design. Instead, allow people to give an email, a refund address, etc. at some point.

We're talking about the original Bitcoin client here. Although this behaviour is largely justified for security reasons, some current or future clients may not mix addresses between accounts and still be compliant at protocol level.


unconfirmed transaction for over 2 days what to do? sent from exchange to wallet  2 days ago still not confirmed ?
https://blockchain.info/tx-index/277169110

The recommended fee for a transaction is of 450 satoshis ber byte.

Your transaction is 226 byte long.

450 x 226 = 101700 shatishi

101700 shatoshi = 0.00101700 Bitcoin

The transaction fee you included is of 0.0003842 Bitcoin which is 0.0006328 BTC lower than the recommended.

I wouldn't be surprised if you had to wait even more.

Data source: bitcoinfees


Tax implications of withdraw fee from one exchange (Binance) to another GDAX/Coinbase I transferred 0.2 ETH and 0.3 ETH in separate transfers from GDAX to Binance (GDAX does not charge a fee for this).

Then, I transferred back from Binance to GDAX all 0.5 ETH, but since Binance charges a 0.01 ETH withdraw fee, I now only have 0.49 ETH in my GDAX account.

Then, I sell my 0.49 ETH on GDAX.

Assuming I would like to report taxes, how do I take into account the 0.01 ETH in transfer fee assuming the following:

0.2 ETH was purchased at $100

0.3 ETH was purchased at $120

0.49 ETH was sold at $400 (within a year)

In other words, what's the best way to report these two transactions on form 8949 (https://www.irs.gov/pub/irs-pdf/f8949.pdf)?

Grain of salt disclaimer:(Consult a professional, lawyer, accountant, doctor as I'm a computer engineer, musician, and painter I'm clearly none of those.)

Also read this https://www.irs.gov/instructions/i8949 if you need to fill out 8949.

I hope this is a clear explanation of how capital gains taxes work in general.

Here's an example of what I would do normally assuming a FIFO tax treatment:

You need to pay tax on your capital gains but you want to subtract your cost basis from the total value you sold for as the basis is not taxed as a gain. (Note that if you can't prove the cost basis I believe the entire sale of 0.49 at 400 would be considered taxable)

{sold value - cost basis = capital gain} that you need to pay tax on (income tax if under 12 months, 15% if it's a long term gain)

First find the cost basis.
(0.2*100)+(0.3*120)=20+36=$56 (this is your cost basis)

(I'm going to round your 0.49 eth up to 0.50 as a clear example with round numbers)

Then compute the amount generated from the sale (I'm calling this a sold value)
0.5*400= $200 (this is your sold value in my example equation)

Now find the capital gain using the equation below:
sold value - cost basis = capital gain
200-56=$144

For long term gains over 12 months it's 15% * your gain minus the cost basis

144*0.15=$21.50 due in taxes.

For short term gain (held under 12 months, as is your case) the gain is considered income.

144*your tax rate = what you owe to the IRS as this was a capital gain. This gets added to your AGI so if you have an AGI of 200,000 your AGI is now 200,144 and the 144 gets taxed as ordinary income.

Regards


configure: error: No working boost sleep implementation found On Ubuntu 18.04 using the /depends for ./configure but I keep getting this error:

checking for boostlib >= 1.47.0 (104700) includes in "/home/tony/crypto/bitcoin/depends/x86_64-pc-linux-gnu/share/../include"... yes
checking for boostlib >= 1.47.0 (104700) lib path in "/home/tony/crypto/bitcoin/depends/x86_64-pc-linux-gnu/share/../lib/x86_64-linux-gnu"... no
checking for boostlib >= 1.47.0 (104700) lib path in "/home/tony/crypto/bitcoin/depends/x86_64-pc-linux-gnu/share/../lib64"... no
checking for boostlib >= 1.47.0 (104700) lib path in "/home/tony/crypto/bitcoin/depends/x86_64-pc-linux-gnu/share/../libx32"... no
checking for boostlib >= 1.47.0 (104700) lib path in "/home/tony/crypto/bitcoin/depends/x86_64-pc-linux-gnu/share/../lib"... yes
checking for boostlib >= 1.47.0 (104700)... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system-mt-x64... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem-mt-x64... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread-mt-x64... yes
checking whether the Boost::Chrono library is available... yes
checking for exit in -lboost_chrono-mt-x64... yes
checking whether the Boost::Unit_Test_Framework library is available... yes
checking for dynamic linked boost test... no
checking for mismatched boost c++11 scoped enums... ok
configure: error: No working boost sleep implementation found.

The command called is

./configure --prefix=`pwd`/depends/x86_64-pc-linux-gnu --disable-wallet

. I've tried this without the depends and with. Tried to checkout to 0.18.1 and on master, but getting same error. Help very much appreciated.

Extra info from config.log

uname -m = x86_64
uname -r = 4.15.0-65-generic
uname -s = Linux
uname -v = #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019

More from config.log here: https://paste.ubuntu.com/p/v6nhPvW68s/

Found the problem. Had these lines in my .bashrc and commenting them out fixed it:

alias gcc="gcc-8"
alias g++="g++-8"
export CC="gcc"
export CXX="/usr/bin/gcc-8"
export PATH=/usr/local/clang_8.0.0/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/clang_8.0.0/lib:$LD_LIBRARY_PATH

Why this caused ./configure to error out, I have no idea. But problem solved.


Will an attacker's forked branch of block chain be used in bitcoin confirmation? From what I understand, transactions are agglomerated into a block, proof of work is done by computing a hash value for the block, then added to the block chain. When a block is added to the block chain, then the transaction included in the block is considered to be confirmed.

How is the full node from which the block chain is queried decided? Or how many full node's block chain is a transaction checked against?

Suppose an attacker has a forked chain, and let us assume nothing about other full nodes' rejection or confirmation about this fork, can my transaction be checked against this forked chain of the attacker and not against other valid block chains maintained by honest full nodes?

Suppose I succeeded in 6 confirmations, but all these blocks are an attacker's fork. Is this a problem?

Your scenario is not completely clear, because you don't tell us whether the attacker is producing valid blocks or invalid blocks. You have also not defined whether your own wallet is a full-node or a thin client.

Let's first talk about how blocks are relayed through the network:
When a new block is discovered, a node will announce via an inv (inventory) message that it has this new block. Other full nodes will send a getdata message, requesting the whole block. After receiving and validating the data, they will send an inv message to their peers to announce the new block to them.
SPV nodes do not request the full block. They'll just get the block header, and if there are any transactions of interest, they'll specifically request proof for those to be sent via a merkleblock message. SPV nodes cannot fully verify the validity of new blocks, because they don't store the blockchain.

Now there is three different possible scenarios, and two types of wallets to consider:

Attacker is producing invalid blocks
A SPV wallet may be fooled, because it can't verify the validity of a block. They still check that the block header's are well-formed. Some SPV wallets require multiple peers to tell them about the same block. Therefore, this attack may require additionally a Sybil attack or control of the SPV wallet's internet connection.
Full nodes are not affected, because they'll reject invalid blocks.

Attacker is producing valid blocks at low speed
A SPV wallet will reorganize to a longer chain when it hears about it from a different peer. So, again, the SPV wallet needs to be isolated from other information for this to work. As the information is valid, this attack may also work against full nodes. The attacked may notice the suspiciously slow update rate.

Attacker is producing valid blocks with 51% of mining power
The attacker is faster than the whole rest of the network. By choosing to only build upon his own blocks, he can mine 100% of the blocks and still outpace the remaining network. The blocks are valid and therefore accepted by all nodes (until some sort of intervention). The attacker can censor transactions and even rollback a small number of blocks by starting from an earlier block but eventually overtaking the natural block chain tip. This is called a majority attack and breaks the axiomatic security assumption of Bitcoin that more than half the mining power is honest.

How secure are six confirmations in an attacker's fork?
If you're caught in a Sybil attack, this will fool you. In every other case, you'll not be fooled, or the whole network is the target.


Would bitcoin be compromised if the officially distributed executable was? From the official Bitcoin FAQ:

Could miners collude to give themselves money or to fundamentally change the nature of Bitcoin?
... Bitcoin is a distributed network, so any changes implemented to the
system must be accepted by all users. Someone trying to change the way
Bitcoins are generated would have to convince every user to download
and use their software

If somebody hacked bitcoin.org, couldn't they send out an update to the Bitcoin protocol/client that contained malicious "steal all your money" code?
Since the update came from official sources, everyone running bitcoin would see this as a regular and standard update, when it actually was malware.

No, Bitcoin would not be compromised, only individual users who downloaded the malware.

For Bitcoin itself to be compromised more than half of all its users needs to be affected, and that is virtually impossible (given it has no auto-update functionality).

So any tampering with the binaries/source will be discovered long before that it can become a problem.


mtgox failure... any implications for bitcoin/ecurrency protocol design? last heard, estimates are Mtgox lost about ~$½B ... apparently the current bitcoin market cap is around ~$8B ie Mtgox failure roughly somewhere around 1/16th the entire market cap of bitcoin, a massive amt (although the market value of bitcoin has been affected up to ¼ of total value during the crash, showing an outsize impact many times beyond total value stored by Mtgox, ie impacting overall currency user confidence). (was Mtgox possibly the largest single bitcoin bank?)

there is some talk in news articles about doing "forensic analysis" on the public bitcoin blockchain. not sure what this will turn up but it raises another question... if any kind of "forensic analysis" can be done a posteriori, why not also a priori? in other words

  does the Mtgox failure have any implication or lessons for bitcoin/ecurrency protocol design/architecture? is there a way to run algorithms by 3rd parties that can identify "banks" like Mtgox that seem to have accountability/stability issues, and esp identify them before they reach massive stability-threatening scale? (aka "too big to fail"?) ie can the architecture itself be built/adjusted with some kind of "fault tolerance" which mitigates such large (near-systemic) failures?

Yes, finances can be analyzed, but there will be wide ranges for accuracy and precision if an institution remains anonymous which would be strange.

Most likely, standards will be built in the financial community around disclosures of BTC for confidence.  Institutions that prefer anonymity or suddenly start showing disparities will probably be shunned with the latter most likely experiencing solvency troubles, exacerbating a run if bailouts cannot be orchestrated.

Welcome to the NFL, cryptocurrencies.


Notify when new transaction is arrive in a bitcoin address I have bitcoin full node on the server. I need to notify when new incoming transaction is arrive into a bitcoin address. Is there any RPC will help to achieve my goal ...

Any help is appreciable. Thank you

Try using ZeroMQ to listen to transaction event.
You can subscribe to hashtx or rawtx events.

Here is a nodejs example taken from this great guide by GR0KCHAIN: https://bitcoindev.network/accessing-bitcoins-zeromq-interface/

var zmq = require('zmq')
  , sock = zmq.socket('sub')
  , RpcClient = require('bitcoind-rpc');

var config = {
    protocol: 'http',
    user: 'bitcoin',
    pass: 'local321',
    host: '127.0.0.1',
    port: '18443',
};

var rpc = new RpcClient(config);

console.log("T")
sock.connect('tcp://127.0.0.1:29000');

sock.subscribe('rawtx')

sock.on('message', function(topic, message) {
  rpc.decodeRawTransaction(message.toString('hex'), function(err, resp) {
        console.log(JSON.stringify(resp, null, 4))
  })
})


BCH ABC testnet Faucet? I want a bitcoin cash ABC chain (BCHABC) testnet faucet.
Cause 15th Nov. onwards after a hard fork on bitcoin cash network existing bch faucets are not working. Even questions over here are also not upto the mark https://github.com/Bitcoin-ABC/bitcoin-abc/issues?utf8=%E2%9C%93&q=faucet

It is started working now.
I guess after stabilizing ABC chain it is started working as expected tried with https://testnet.wormhole.cash/faucet/

https://coinfaucet.eu/en/bch-testnet/
Thanks.


Bitcoind move address to other account When I move an address to another account, and the address contains bitcoins, will the person who gets the address will get the bitcoins that where on the address?

Short answer is no. Accounts are a way to keep track of coins in "sub-wallets" of your wallet. When you receive coins to an address, the balance of that account is increased. After that, though, the link between those coins and the address balance stops.

Moving the address to a different account doesn't take all coins that the address has ever received with it, it only indicates that any future coins received on that address should go to the new account specified.

Similarly, moving the account balances doesn't change the amount received/owned on a particular address. Accounts are really just an accounting feature to keep sub-wallets, but moving money around in your accounts doesn't actually move them on the blockchain.


Longest-time-verifying block I heard that there was an old block with one transaction and it takes 20 seconds of CPU time to verify.

1) Which block was it? I forgot its block height.

2) Is there a block that takes more time to verify? Or is there a similar block?

I'm not completely sure if this is what you are looking for, but it may be.

Here you have a type of transaction that takes 3 minutes to verify, and that was reported back in 2013. (CVE-2013-2292). Moreover, in Sergio Demian Lener's blog you can find a related topic, where he explains how he found a vulnerability that used the FindAndDelete function and OP_CODESEPARATOR to create a transaction that toke up more than 5 hours to verify.


micropayment channels, n-m addresses, interoperability I just read bitcoinJ's working with contracts tutorial and I am puzzled as:

it seems to me that n-m addresses are implemented in Bitcoinj using plain multisig (as defined in this bit of the developer's guide, and discussed here)
I looked for implementations of addresses controlled by more than one private key with pybitcointools (tutorial on that here) and on libbitcoin's wiki. It seems to me that these two libraries use P2SH.

Most libraries seem to use P2SH, but bitcoinJ chose the other way it seems (or is it?)...

In an implementation of micropayment channel with bitcoinJ on one side and, say, libbitcoin on the other ; will the two sides be able to interoperate?

(edit: I m talking here only about unidirectional payment channels)

Thanks

Not necessarily interoperable.

Firstly, libraries have to agree on what kind of parameters to exchange and how they are exchanged. There's no guarantee that the parameters required by bitcoinj and libbitcoin are the same.

Secondly, it is now considered standard practice to create P2SH transactions regardless of what kind of transaction you're setting up, unless it is P2PKH. In the case of P2SH transactions, you then have to assert that the payment channel protocol would also be able to parse/recognise/understand the redeem script provided by service provider of the payment channel (assuming that you're talking about a single-direction payment channel).


Send and Receive BTC with Same Address from 1 Person Is it possible to :
I sent BTC to A from Address1 and I asked him to send me BTC (different amount as I send him) to Address1 (same address with I sent him before)..?

Yes, this works, change either needs to be sent back to Address A, if the amount is less, or an additional previous transaction output needs to be used if the amount is greater than what was sent from Address1. Here is an illustration of change.

Let's say 1 BTC is sent from Address A to Address B. Then 0.5 BTC is sent from B back to A.

TX #1

Input                         | Output
----------------------------- | ------
(some output 1 BTC to A)      | 1 BTC to B

TX #2

Input                         | Output
----------------------------- | ------
(TX #1 output 1 BTC A to B)   | 0.5 BTC to A
                              | 0.5 BTC to B (change)

Note this doesn't account for tx fees, which would decrease the change amount back to A


Saved .bitcoin directory full ~9 GB block data, won't work when copied to another system I had to delete my .bitcoin directory in Ubuntu 12.10, after months of getting the near 9 GB of blk data files.

I copied everything over to another machine (and back to the original too) and it gives me:

  A fatal error occurred. Bitcoin can no longer continue safely and will quit.

     EXCEPTION: St13runtime_error
     CDB() : can't open database file blkindex.dat, error 22
     bitcoin in Runaway exception

I tried chmod +w on the files, but still no go.

Two things come to mind as possible reasons.

The most probable reason is that you've switched client versions. There was a switch between 0.7 and 0.8 in how the block index (not the block data itself) was stored; it was changed from BerkeleyDB to LevelDB. If you remove the blkindex.dat (and really want to keep an index around, which is unlikely) you can restart the client with -rescan and -txindex. It will take a while (an hour?) to complete the indexing.

The other reason that I can think of is that it's genuinely corrupt, but that's unlikely.


Does `importprivkey` need a rescan even in a txindex=1 node? Documentation for importprivkey RPC command has an optional boolean argument called "rescan" which hints that the user may want to rescan the blockchain to be able to see previous deposits to this address.

Is the rescan needed if the node is configured as txindex=1?

Yes. txindex=1 is not related to the wallet and the wallet does not know about the txindex nor does it care. What the wallet really cares about is transaction output information and which transactions are related to addresses stored in the wallet. The txindex does not store any of that information, all it stores is the location of each transaction identified by transaction id. The actual contents of that transaction are not kept except in the raw transaction itself.


What are some open source blockchain projects? I was trying to build a blockchain to host my cryptocurrency.For that I was searching for some open source blockchain projects and I came across Best blockchain open source projects which mentioned names like :

Eris
MultiChain
HydraChain
OpenChain

I was concerned whether these projects allow you to build your own blockchain or they just let you build something like a Dapp on their blockchain?

The most famous open source Blockchains are Bitcoin Blockchain and HyperLedger Blockchain.


What can an attacker with 51% of hash power do? Suppose organization X has 51% of the hash power for a period of 1 week. In this week, what exactly can and can't X do?

Actually, it's very easy to do damage to the network once you have 51%; just build your own chain faster than the network, and broadcast it whenever you like. If you send some of your coins to a new address in your own chain, all the transactions issued in the live network by spending those same coins will be reversed at the moment the longer chain is broadcast.

Right from the bitcoin wiki (probably proof-read by many pairs of eyes) :

  An attacker that controls more than 50% of the network's computing
  power can, for the time that he is in control, exclude and modify the
  ordering of transactions. This allows him to:

  Reverse transactions that he sends while he's in control
  Prevent some or all transactions from gaining any confirmations
  Prevent some or all other generators from getting any generations

  The attacker can't:

  Reverse other people's transactions
  Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
  Change the number of coins generated per block
  Create coins out of thin air
  Send coins that never belonged to him

  It's much more difficult to change historical blocks, and it becomes
  exponentially more difficult the further back you go. As above,
  changing historical blocks only allows you to exclude and change the
  ordering of transactions. It's impossible to change blocks created
  before the last checkpoint.

  Since this attack doesn't permit all that much power over the network,
  it is expected that no one will attempt it. A profit-seeking person
  will always gain more by just following the rules, and even someone
  trying to destroy the system will probably find other attacks more
  attractive. However, if this attack is successfully executed, it will
  be difficult or impossible to "untangle" the mess created — any
  changes the attacker makes might become permanent.


Is is possible to prove you possess an amount of BTC without actually spending it? I could think of several situations, especially in large purchase negotiations, where one party would like to know that the money is under the control of the other party before continuing with the costs of further negotiation and due diligence (e.g. $5k in a house closing).

You can sign any text with the private key you own and anyone can verify that with a public key associated with a given Bitcoin address. As long as you make the message relevant to the conversation, say "This is LethalFractal, at 2013-09-07, I claim ownership of address 1234567890... as a proof for negotiations with John Smith", the person can know that it is in fact you owning a given address, and since they can check the balance of that address, you will have proven that you have access to that money.


Lightning network routing failure rate Let's say a lightning node A wants to route a payment to a lightning node B, being A and B not directly connected.A looks for routes throughout the network, using the info about the total capacity of available channels and construct n possible routes to reach B.

Will A just try routes until eventually one of the n succeeds?

For what I've got by checking the BOLTS, the actual state of each sides of the channels is not announced (is it?), what means that even though a route could have enough capacity to route a payment, one of the channel could be unbalanced and the whole route may fail. Therefore, the potential failure rate when trying to route payments seems quite high.

Am I missing something?

Indeed, the current state of the channels is not announced (it is allegedly hidden for privacy purposes). Therefore, A does not know if a route has enough capacity until he tries to make the payment throught that route.

A recent study claims that success rate is around 80% for USD 1.2, but only about 1% for transactions larger than 200 USD.

Related question: In lightning network, is the balance publicly anounced in realtime?


Lightning Node hardware Will I, or anybody have more capabilities with a Lightning Node, that is CPU or GPU Powered?
For instances a more powerful computer vs Raspberry Pi’s

Will I, or anybody have more capabilities with a Lightning Node, that is CPU or GPU Powered?

No
I believe all implementations of Lightning nodes are CPU based. There doesn't seem to be any need for using GPUs to accellerate any mathematical computations.
I assume we exclude budget microcontrollers from what you mean by "CPUs". We are talking about CPUs found in general purpose computers on the market today that have at least some usefulness as typical light-usage desktop computing devices.

For instances a more powerful computer vs Raspberry Pi

It seems you can run a Lightning network on a Raspberry Pi 3.
Having a faster CPU doesn't give you any specific financial advantage over other people. It just makes the computer more responsive in interactive use.
A faster CPU might enable your lightning node to run more channels (or something) or act as a gateway for a higher volume of traffic - but as I understand it, the financial benefits are absolutely insignificant.
I'm not certain what sorts of capabilities you are concerned about but it seems that a typical usage of a lightning node is not especially CPU intensive.

References:

Bitcoin Lightning Node on Raspberry Pi


Are there clients that manage several alts? E.g. a desktop client that can manage, in a unified UI, Bitcoin, Namecoin, Litecoin, PPCoin...?

Ufasoft open source client can manage different alt-coins, most of them with same private keys.

https://bitcointalk.org/index.php?topic=58821.0

PD: be careful, some users have reported malware in Ufasoft mining software.


Why doesn't BTC reward miners for confirmations, too? Currently as far as I know when a miner discovers enough 0s, he
broadcasts his solution to the network in order to win the coins.
While, he broadcasts his solution (which gave him the 0s), he also
verifies some transactions.
When miner verifies transactions, the gives priority to the transaction
that pays the highest confirmation fee.
As far as I understand, when the miner verifies transactions that do not
pay any confirmation fees, the miner doesn't get any rewards for doing so.
In such a case, the miner has absolutely no reason to care to verify it.
If the miner verifies such a fee-less transaction, he does it purely
because he is just a kind person, but no monetary incentives for this act.
My question is: why doesn't the BTC protocol define the BTC reward
function as a function of the solves 0s and as a function of number of
confirmations?
Specifically, I propose this reward function:
btc_reward = ZEROS_DISCOVER_REWARD
for transaction in confirmations:
    already_has_n_confirms = get_confirms_num(transaction)
    confirm_reward_rate += L / (1 + E**(K*already_has_n_confirms)
    btc_reward += confirm_reward_rate * CONFIRM_REWARD
    btc_reward += confirmation_fee # could be zero, and miners would still
                                   # have incentives to confirm, because
                                   # the btc network still rewards by
    other means.

where L, E, K and CONFIRM_REWARD are variables that need to be
tuned to adjust BTC's inflation/deflation targets (similar to like how
ZEROS_DISCOVER_REWARD is defined).
Of course this is just a suggestion for funrction with an exponential decay
as a function of number of confirmations a transaction already has.  E.g.
transactions with no confirmations are in a more disperate situation to get
some confirmation that other transactions that have, say, 10 confirmation
salready.
This way, miners will have a monetary incentive to confirm all transactions
even those that pay no confirmation fees, which will effectively reduce
the resistance against trade in the BTC world, and make BTC even more
attractive.
At the same time, people who are in a hurry can still put
their fees to get their confirmations faster.  But at least, those who are
engaging in a low-cost economy that is sensitive to fees at least have the
liberty of having a free monetary system.
Any thoughts on why this isn't done?

I'm not 100% sure I've understood your suggestion, in part because you've used some non-standard terminology.
But it looks like this is actually two suggestions rolled into one.
The first is a mechanism to incentivize miners to include transactions which have little or no fee.
That is a bug, not a feature, for two reasons:

Including transactions in the blockchain is costly. Every transaction needs to be processed not only by every node that operates now, but every fully validating node that will ever start operating in the future. The more transactions there are, the harder it is to run a node, and the less decentralized the system is.
This is why we don't want people to have the opportunity to spam the network with transactions of low economic value (due to either negligence or malice). If someone wants to have their transaction included, they have to pay for the privilege. That's why there is a limit on the block size, and users compete with fees on the right to enter the block.
Low-value payments is what we have the Lightning Network for.

A core principle of Bitcoin is to have a known monetary policy. Every reward obtained by a miner has to come from somewhere. Either from the pre-agreed inflation schedule for Bitcoin, or from already existing coins paid by users as fees. You are suggesting that miners should be paid above and beyond the inflation schedule and the user fees. Where will the money come from?
This problem is not completely insurmountable - but it's not really a simple matter of tuning a few parameters, and it does complicate the issue.

Your suggestions also seems to hint at the possibility that fees for a transaction will not be just given to the miner who includes it in a block, but rather divided between that miner and future miners who built on that block. This is similar to what I suggested here. But this is not really effective enough to be worth the trouble.