The easiest way if you come from web development and or you want to put a system in production is to use the most stable and updated implementation/API of Bitcoin Core

note: after downloading it it's best practice to check the md5/sha of the file you downloaded on bitcoin.org to be sure your installer is genuine

1) Install Bitcoin Core

2) Use it's CLI or JSON rpc APIs: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

there's no step 3!

This in the case your target is to run an app connected to most of the updated nodes, have the latest code with security fixes to at least sign and broadcast transactions, and obviously, query the blockchain!

glhf


When is a new block added to the bitcoin blockchain and is it vulnerable to modifications till then?

a block is assembled by the decision of a miner. If he wants to, he cannot include transactions at all. If he includes tx, then he uses tx out of his mempool. tx are normally verified before entering into a block. If the miner decides to tamper with a tx (change its contents), then when sending the block to the network, other nodes will reject this block, cause it contains an invalid tx.

  Until a transaction is added to a block ... how are the transactions tamperproof?

tx be tamperproof doesn't make sense, while the block is created. It is at the risk of the miner! If he wants to win the block reward, he better transmits correct blocks into the network.
The whole idea of bitcoin is, to better play well and get incentivized for it. If you try to play against the network, you have enormous costs to carry.


Since the blockchain is public, how can we see it?

The blockchain is the decentrally maintained append-only log of all
transactions verified on the Bitcoin network. There are multiple websites, so called blockchain explorers that visualize this data on the web.

Indeed all transactions that ever happened on the blockchain are publicly visible, and looking at transactions on such a blockchain explorer let's you discover what transactions moved the same Bitcoin balance before you received it.

While all the transactional information is in the public, the involved parties remain private as they transact under pseudonyms called Bitcoin addresses. We can see time, volume, and involved addresses, but don't learn the individual's private information.

However, through data mining observers may learn that some addresses are under the control of the same entity and might make some guesses about their usage.


collecting block reward and transaction fees

Miners independently create coinbase transaction for block. To create coinbase transaction this transaction should be first in block and have only 1 coinbase input. Coinbase input means that outpoint transaction is 0000000000000000000000000000000000000000000000000000000000000000 and output index is FFFFFFFF. Inputs amount fro transaction calculated like block reward amount according to block height, plus all fee amounts for all other transactions inside block. Miner able to take this total amount on outputs. Miner specify own address and amount of block block reward plus fee reward. In case the miner incorrectly calculates amounts and specify greater than expected, block will be rejected by other nodes. In case miner specify lower block will be accepted, but miner lose money.

Example in mainnet when miner lose all reward due to an error:

https://bitaps.com/410995608537d591d6ce5ff2a7966fa84f891c5e2269ef85e8ecdb68d5188f9b


What changes did segwit do to minimum transaction fee?

As you point out, paid fees result from two phenomena:

Full nodes on the network enforce a minimum feerate for relay, which in recent history has been 1 satoshi per byte.
Miners sort unconfirmed transactions by fee per byte, and include the highest ones first in blocks (whose size is limited to 1000000), as this maximizes their income. This results in a fee market where transactions pay according to supply and demand for space in blocks.

This means that while 1 sat/byte is the minimum to be relayed, it's not enough to actually get into a block, and as a result this minimum has become mostly irrelevant.

SegWit did not change these processes. There is still a minimum feerate of 1 satoshi per byte, and there is still a fee market.

What did change is the definition of size of a transaction. In SegWit, a significant portion of the transaction data is moved to the "witness", whose size only counts at a rate of 0.25. So for example a 200-byte non-SegWit transaction would be counted for the full 200 bytes, and 5000 of them would fit in a 1M block. If this were an equivalent SegWit transaction, maybe 120 out of those 200 bytes would be in the witness, resulting in an effective size of 80 + 120*0.25 = 110. Now 9090 such transactions fit in a block. The result of this new rule is that the optimal selection policy for miners also means looking at fee per byte, where bytes refer to this modified definition that discounts witnesses.

TL;DR: SegWit makes transactions cheaper by discounting portions of the data.


How do I find the nodeid of the node issuing a lightning network invoice?

Lightning invoices are signed by the node issuing the invoice in order to verify the signature we need to know the node id. Thus it is included in the invoice. Lightning nodes provide an API to decode invoices.

In c-lightning you can do (lnd below!)

lightning-cli decodepay LNBC13934430N1PWJUJEZPP5K7FLC2M5CLHTWMTF3HZDN7VVRCA4RNFAFA89F2D6KGYWW4JCSDAQDZ62PSKJEPQW3HJQ4RGV5SYC6T8DP6XU6TWVUSYXMMWVEJHYETWVDJJQ2Z0WFJX2U3QF9ZR5GZ5F3PNZWFD25UY54Z39YXQZURCQP2RZJQG8ZM9WXGVHZPMUQEWY9J9KDQNRVLZHPCWM6S8CVLC2CKRDNELE42Z9U5VQQY3SQQYQQQQL8QQQQPJQQ9Q6KM84F7KTW6UV574UR2LFNKZLM7VNK8NJRZV20JD8SAW6FZ3TQGSZE6YUT0X2UXGDGYJZGTXEFSQSSEVTKFF97P3TER5K23ZPHDDXHQQ95UT4N
{
  "currency": "bc",
  "created_at": 1563314978,
  "expiry": 899,
  "payee": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365",
  "msatoshi": 1393443000,
  "amount_msat": "1393443000msat",
  "description": "Paid to The Lightning Conference (Order ID: TLC19-U8JTQ)",
  "min_final_cltv_expiry": 10,
  "routes": [
    [
      {
        "pubkey": "020e2d95c6432e20ef80cb885916cd04c6cf8ae1c3b7a81f0cfe158b0db3cff355",
        "short_channel_id": "572579x582x1",
        "fee_base_msat": 999,
        "fee_proportional_millionths": 200,
        "cltv_expiry_delta": 40
      }
    ]
  ],
  "payment_hash": "b793fc2b74c7eeb76d698dc4d9f98c1e3b51cd3d4f4e54a9bab208e75658837a",
  "signature": "3045022100d5b67aa7d65bb5c653d5e0d5f4cec2fefcc9d8f390c4c53e4d3c3aed245158110220016744e2de6570c86a09212166ca6008432c5d9292f8315e474b2a220ddad35c"
}

In particular we find the entry which reveals the node of the store:

 "payee": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365"

We can query the gossip store for more information about the node with the following command:

lightning-cli listnodes | grep 024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365 -B 1 -C 13
    {
      "nodeid": "024a8228d764091fce2ed67e1a7404f83e38ea3c7cb42030a2789e73cf3b341365",
      "alias": "www.fulmo.org",
      "color": "f2f3f4",
      "last_timestamp": 1561973177,
      "globalfeatures": "",
      "global_features": "",
      "addresses": [
        {
          "type": "ipv4",
          "address": "95.211.207.81",
          "port": 9735
        }
      ]
    },

This gives us all the information we need to peer with the shop and fund a channel.  (In case the node was private we could use the routes hints from the decoded invoice to connect to a public exit node.)

lnd users

If you are using lnd you can use the command DecodePayReq and instead of invoking listnodes to get the information from the gossip store you can invoke GetNetworkInfo


api.pro.coinbase.com retrieve historic candles data

Im working on the same thing. You have to repeat the request.

For 1000 candles you need to loop the request 3-4 times with different start and end parameters.

I had it working for hole hours but now that I switched to minute granularity the request comes out weird.


Only 10 connections on my raspberry pi full node

bind=127.0.0.1

Binding the p2p port to localhost means that it can not accept incoming connections from anywhere other than software on your own machine.

listen=1 #enable download of new data

This allows incoming connections to whatever is configured by bind, it doesn't have anything to do with downloading data yourself.


I need a bitcoin or usd payment for my site

Checkout the Coinbase API: https://developers.coinbase.com/

Coinbase is very well known and trusted.

Then for the USD option you could have another button that links to Paypal, Stripe, 2Checkout, etc..


What EURO exchanges have web APIs currently?

There are quite a few exchanges in Europe with APIs. Use the Bitdango exchange search to find exchanges in European countries:

http://bitdango.com/exchanges?countries=BG,CZ,DE,FI,FR,GB,HR,MT,NL,NO,PL,SE,SI

Or use the Bitdango market search to find markets that use Euros as quote currency:

http://bitdango.com/markets?quoteCurrencies=EUR


Rationale behind accepting btc as a mode of payment?

Sending a Bitcoin payment incurs a fee relative to the weight of the transaction. Every transaction must have at least one input and one output. Assuming a minimal transaction weight for either, it costs the same to send 1 mBTC or 100 BTC.
The cost per transaction weight is one reason why on-chain transactions are ill-suited for micropayments, but it also means that larger payments can come at a significantly lower relative cost than other payment forms.
A new Tesla 3 costs about 0.9 BTC today. At a feerate of 150 sats/vB (next block confirmation even at high demand) and a transaction weighing 250 vB, the transaction fee of 37,500 sats (0.375 mBTC) translates to a relative fee of 0.0417%. I believe that you will find many other payment forms to incur a larger fee, especially for the merchant.
On the other hand, payments on the Lightning Network incur a cost relative to the paid amount, so I expect smaller payments to shift to Lightning Network and similar solutions more and more.


Can a Bitcoin ( or any other cryptocurrency ) be compromised with a large botnet/s?

Could a large botnet disrupt/hack the whole cryptocurrency system if
  the botnet currently holds more CPU power than the friendly nodes?

Yes, this is known as 51% attack. The malicious attacker should control >50 percent of hashing power in the network.

  If yes,would it be feasible at all and or worth the work?

Current network hashing power is around 11 million TH/s. So the attacker should buy another 11 million TH/s. Bitcoin Antminer S9 has 14TH/s so you should buy around 800 000 of these. Let's say one is 2000$ so you have to invest 1.6 billion $.

So it is relatively feasible. (Especially when the current bitcoin market capitalization is $136 billion)

Check also: Would any of the current botnets be able to launch and sustain a 51% attack?.

About is it worth it: this depends of what you consider by worth. It will probably make irreparable damage to BTC if 51% attack is successful, is that worth  investing 1.6 billion $. You can check if there is similar question of what 51% attacker could achieve (he can not gain 136$ billion of bitcoins) for more info.


I want to display information about my bitcoin node on a webpage (php or html)

The node example is my node, this is the script that I'm using.

Download this script
http://pastebin.com/wKytLZmc

Put it anywhere on your server and change the RPCUSER/PASS, NODEADDR and BITCOINADDR.

Run the script to update every time. You can also use it to create a chron job.

To run the script, after editing the values above, put it anywhere and type:
python btc-update.py

If it just returns, that means it works :)

Note: If you get an error, you’ll need to install BitcoinRPC for the script to work.
Go here: https://github.com/jgarzik/python-bitcoinrpc
Follow Jeffs simple instructions. Once BitcoinRPC is installed, run the node script again and it will update!

Good luck!


Expected value in pool mining vs. solo mining

You are assuming that Cecil and Danny can collaborate to avoid duplicating work. They can't, at least not in any meaningful way. In your example, there are a small number of boxes for them to search. In Bitcoin, there are trillions of boxes. Any collaboration about keeping track of who searched what would take much more work than everybody searching randomly and accepting the extremely small probability of checking the same thing twice.


decompressing Multibit wallet private key in another wallet

Check out https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial to brute-force the password, however, you will need many CPUs. If you need help, contact me.


What was the longest held UTXO ever spent?

As of June 19 2019, using the following query:

bitcoin-indexer=> select reverse_bytes(output_tx.hash_id || output_tx.hash_rest),
 output.tx_idx,
 output_tx.current_height,
 input_tx.current_height,
 input_tx.current_height - output_tx.current_height from output
 inner join input on input.output_tx_hash_id = output.tx_hash_id AND input.output_tx_idx = output.tx_idx
 join tx as output_tx on output.tx_hash_id = output_tx.hash_id
 join tx as input_tx on input.tx_hash_id = input_tx.hash_id
order by (input_tx.current_height - output_tx.current_height) desc limit 40;

against fully indexed blockchain (using rust-bitcoin-indexer), I was able to identify the coinbase of d5a045c9d8a5bf7619c52968945c494d49333b80d51f1d0e2747b9e8bb2c6709 as the longest held UTXO ever spent (so far).

It was created in block 45697 and spent in block 559367, which lasted 8 years 10 months and 3 days.

The full set of results:

                           reverse_bytes                            | tx_idx | current_height | current_height | ?column?
--------------------------------------------------------------------+--------+----------------+----------------+----------
 \xd5a045c9d8a5bf7619c52968945c494d49333b80d51f1d0e2747b9e8bb2c6709 |      0 |          45697 |         559367 |   513670
 \x67e8d773078b75fb5680089b8d2d380be93943a1dcf9c37e309d517a98e5d40c |      0 |          66188 |         570705 |   504517
 \x9c90d07be3d18c7a3612cd971934ed89c0d07fa302d4922481d1114dfaedc93d |      0 |          73303 |         577470 |   504167
 \x7a8a36f68d265ff49e4df5215a2a6dd922dbfbb6cc695399d2b10efd4a75c47d |      0 |          52632 |         553012 |   500380
 \x08ca56db26ad6d171e7fbcb24e592590bf369d70fc5931eb3790278681f35768 |      0 |          52644 |         551281 |   498637
 \x5fba526502ee887bc1e6beb0255cfcdfaaf41e0d25e233e447e585458ed37ac5 |      0 |          52652 |         551281 |   498629
 \x9596d84e671daea6ee965244ca75e204dfa72a471db3cb51dc406fbfeacc2e92 |      0 |          69951 |         567828 |   497877
 \x82b6f02c86fd3afb5ca23b7bf88d509e92516129dc36ceb4864114ed5ec710f5 |      0 |          66446 |         563621 |   497175
 \x31a67bf1f3cf01351b76cb16931ceb45c670b50af850181ab586d97040d90a1b |      0 |          82729 |         579816 |   497087
 \x463b0f7c96214418af0f50836047ce0e9cbc5940b739d7d67eed1842e2edf768 |      0 |          82944 |         579816 |   496872
 \x508d7a4ff36cda617aecd02da86fd5449176b0c75d3e398242253dbce6d54eeb |      1 |          83477 |         579817 |   496340
 \x4e0584a90c9dce50ecd9ed1b2d79a3a8af0f690041dccc035fd81f06ac200571 |      0 |          56710 |         551275 |   494565
 \xc6c9e4be37ea843fe50df740b5acba5d23c894a4b68191b1c157b281a8a985c5 |      0 |          74897 |         568169 |   493272
 \x9296baa58de452d15763079e71861f5580863c462ce855a41e485e92f28f6e98 |      1 |          68586 |         560782 |   492196
 \x404116e265c3717b403697ea226f6d839a24f88009b1802b978b692edca95cf4 |      0 |          59137 |         551279 |   492142
 \xf6a0cc22d749a299c83c86df3406b9d6d9e6a70215978363ef5e884812112461 |      0 |          60717 |         551279 |   490562
 \xa28a27378b3499997d1c990813adddbd25e470e0b44510896435b9a918968a0b |      0 |          61047 |         551272 |   490225
 \x36a230b30815e40d238f27f2654ff3681f6c1931076e90c4c05065002b9d91e6 |      0 |          73788 |         562598 |   488810
 \xdcc71895e1baf0abb83ff27348211662b517105b18789f4410a55a51dc50a156 |      0 |          66637 |         555282 |   488645
 \x899ee05d5c4e91b3ee49958a9d0333ff9b1987c352d946ecdb1fd91588f667ac |      0 |          66336 |         554738 |   488402
 \x6284dc97c5c923308675e9b0db88210ad61a42815caaf024b07cc0eb9e262c67 |      0 |          33538 |         521167 |   487629
 \x56102337f6f10161a2286fe1ffb91e353b13a17db6a41c6149574d6dae476528 |      0 |          33590 |         521167 |   487577
 \xf398b7e93220747aa2f45f36284606b2ae802741160f28f2fd3f2afa40bfd346 |      0 |          66627 |         553372 |   486745
 \x708d840ea0041386b4376896b14e510d0cad3cdaeb707fe93ab2d33372723503 |      0 |          68283 |         554738 |   486455
 \x452e2d312a18d907f2ef1ec976b1ed18ef2f5a079ee47037a346f260bad339e2 |      0 |          33784 |         519776 |   485992
 \x0c1739923133af9f52a5764227f2da487f5f4520b5d0127c0867062a311cfeca |      0 |          65671 |         551393 |   485722
 \x6f69ff89b936ac2120cbdc824138022de749977202153680b199bfb1d8afba75 |      1 |          89869 |         575308 |   485439
 \xfcc26559921b51b07cf81d858689a4007fc9cf8fad96d4394da89e3e2d1a1299 |      0 |          91948 |         576386 |   484438
 \xd1ff751609b5a74f99573d7d7baa1c1dc493c9bebd586f6bf381ee0877282ed2 |      0 |          97810 |         579234 |   481424
 \x583b6351a67d96fc42c5294ee4282616c5bd1481e464720cb959fa4c3a5ce192 |      0 |          70534 |         551654 |   481120
 \x836f332753244b3eaa6ea80ddcd59d6727de8874abef09f5f5bfa44d05025d05 |      0 |          70541 |         551654 |   481113
 \xee2feeca4e02840b7036e28045a5dfd06ab65af5b1068cd9598ec3b87d4f4b32 |      1 |          70542 |         551654 |   481112
 \xb0d701da413083e89f00f824a8300387ded7671ca3ca967811c758019cfaf3ba |      0 |          93709 |         574785 |   481076
 \x23b140fb832912031596256b184010e52e24cf66da94dabc80770970087d2f82 |      1 |          92499 |         573193 |   480694
 \x7712a8c8752090e8fa9527603ed08f72b00ace2b9a495d91e78523ff50844182 |      0 |          77095 |         555959 |   478864
 \xed151ae3b0d1cd50df1f97cc4b8747d185b56f54f5aef3754079faa089e3e783 |      0 |          83936 |         561411 |   477475
 \x8d432c241971e25172268765b219d6ed82c3868981a85c9189812b57ddd28912 |      0 |          97972 |         574951 |   476979
 \xcfc9154235db58abd3f09bfd277b084a95ccbd03ed2161d0ab4ef4ed36166821 |      0 |          84411 |         561076 |   476665
 \x5ad52480756416f6288be488f14392799c0ea2d050f96d4306b846d516b02f80 |      1 |          82966 |         558812 |   475846
 \x269bbd2cd3dd7f88da4ca7086e75d36f0d2d4a54b1b5f0ed7509f7375cc71715 |      0 |           3607 |         479423 |   475816
(40 rows)


Buying selling of cryptocurrency. Where does the coin come from and where does it go?

I am a novice trying to understand selling and buying of crypto currency. I could not find it on google so asking, please do not be harsh.

No worries, we all start out here.

  Say, I have an account with coinbase and want to buy bitcoins or other cryptocurrency, how does/where from an exchange gets those coin to sell to me?

They already have a good stock of Bitcoins ready to sell you.

  and If I want to sell my coins whom does the exchange sell it to.

It is different for some exchanges. Some will buy them directly from you to get stock of them, and others will put them up for other users to buy, and the exchange will act as a middleman.

  Is there an article on how this trade work on the internet?

Yes, a simple search should provide you with many resources.

Hope this helped!


Have a look at the early sources here: http://www.bitcointrading.com/forum/bitcoin-clients/original-bitcoin-source-code-archives/

there is a small piece of code in script.cpp:

    case OP_RETURN:
    {
        pc = pend;
    }
    break;

which allows to spend ANY UTXO with just a very simple scriptSig OP_1 OP_RETURN


What are some forks of Bitcoin that ultimately failed?

It kinda depends on your definition of "failed".
See http://mapofcoins.com/bitcoin for a list of maybe not the whole tree, but a fairly large one. You can select "defunct" coins at the top, to mark those. Click on the symbols at the right to get info on that coin.

Now, defunct on that site seems a hard bar to reach, despite the high number of those. For just "failed", you can probably add a whole lot more,

Maybe the most notable failed/defunct one (not because it's known, but by its descendents) could be Tenebrix, which begat Litecoin.


What happens when a transaction is included in more than one block?

If both blocks are broadcast at the same time, and we assume both miners are equally connected to the network, a fork may occur.

Since the default mining policy is mining on the top of the longest chain, or the first one heard in case of a fork, the network should mine in two different blocks until a new one is found, moment when all should go back to "normal".


Any multi-currency accounting ledger that lets me use BTC?

Just found Kashoo.  Freemium, or $10/month.  Haven't used it yet though.

http://www.kashoo.com

Also, what might work, Aqilla:

http://www.aqilla.com/multi-currency-ledger

Infinity PFM (Personal Finance Manager) can read transactions from the Bitcoin.org client:
 - http://launchpad.net/infinitypfm

Ledger:

http://www.ledger-cli.org  <-- Command line only, no GUI.
http://www.reddit.com/r/Bitcoin/comments/155gw5   <--- Writeup


The problem might be that TradeHill adds orders to the Orderbook before processing them.
For example, this happened today:

Around 18h10 UTC, the highest bid was 4.842524 and the lowest ask was 4.840000
Around 22h00 UTC, the highest bid was 4.820000 and the lowest ask was 4.819900

I have also detected similar situations at ExchangeBitcoins.com.  CampBX  and MtGox seem to be matching orders before displaying them so you shouldn't have these problems there.

If you don't want to risk putting an order that will never go through, you should detect situations like this in your code and wait for the orders to solve. If the lowest ask is lower than the highest bid, something is not right.


Why does Bitcoin Core not produce a Reject message for Conflict TXs?

Because it is a waste of bandwidth to convey information that your peers should be calculating themselves anyways. It is also a bad idea to rely on peer's calculations of whether a transaction should be rejected or not because they could be lying to you.


Why some blocks didn't use full potential of their size?

Probably because a winning nonce/hash was found before they were able to fill up with transactions. There's no incentive in Bitcoin to make blocks fill up with transactions. In fact, there are blocks with no transactions (besides the coinbase one)!


Put your client into regtest mode. This allows you to mine an arbitrary amount of blocks very quickly. Add this to your bitcoin.conf

regtest=1
daemon=1

Generate the blocks. Run

bitcoin-cli setgenerate true <number of blocks>

where X is the number of block you want. You'll want at least 101 blocks.
See the mined blocks. Run

bitcoin-cli getblockhash <index>

to get the hash of block number <index>. Then take that hash and run

bitcoin-cli getblock <hash>

Repeat Step 3 for each block you want.
Send the Bitcoins to a new address. Run

bitcoin-cli getbalance

to find out your balance. Run

bitcoin-cli sendtoaddress <address> <amount>

If you don't need to see the contents of the block, you can skip steps 3 and 4.


You're in luck, because I had a similar issue, and just finished making a tool to export private keys from old hive wallets. First, you should search your system for bitcoinkit.wallet, which is the file Hive used to store the wallet.

Then, go here and follow my instructions.
https://github.com/JesseCorrington/bitcoinj-wallet-export

Let me know if it doesn't work, I only tested this on my wallet, which was a non deterministic wallet with encrypted private keys. If you had a different type of wallet it likely will not work. Bug me if that's the case and I can see about updating my code.


One possible reason may that with Bitcoin Core 0.13.1, it was mandatory to use SegWit-compatible mining software. When SegWit transactions are included in a block, a coinbase commitment to the witnesses is required by consensus rules. As the eventual selection of transaction in the block is done by the mining software, old mining software cannot be used to construct a SegWit block. On testnet, SegWit (BIP141) has been active since May 2016.

In Bitcoin Core 0.14, a change was made that permits old mining software to continue to operate. When such software is detected, Bitcoin Core will simply return a block template that excludes any SegWit transactions, alleviating the need for a coinbase commitment.


How can I connect to bitcoin-qt client with public ip address

You need to forward the port if you're in a LAN.

You need to add the IP of the server who is making the JSON-RPC call to the bitcoin.config file such as below:

rpcallowip= IPMakingTheRequest


Is it necessary for all miner to reset mining when the tip of blockchain has changed?

Correct: when block B is broadcast and validated, all miners need to construct new blocks containing a hash of block B's header.

However, it takes only a minuscule amount of computer processing time to construct a new block, so there is effectively no such thing as "restarting work".  Mining is specifically designed to be progress-free: you have the same chance of finding a valid block after a millisecond of work as you do after an hour of work.

Progress-free mining means that a miner with x hash rate should produce n blocks over time, and a miner with 2x hash rate should produce 2n blocks over time---there should be no special advantage to the more powerful miner.


Payment confirmation (3rd's party point of view)

Why not require the merchant to have a unique address and not allow reuse? They could give you an xpub so you can generate them yourself if that's easier. You don't care if the buyer reuses her address.

I'd be careful with depending on time frames. That sounds fragile.


Is there any consensus over specific improvements Bitcoin needs?

There is no consensus. I think part of the reason for that is that many people involved in the Bitcoin project have a vested interest in maintaining that there is nothing wrong with Bitcoin.

In fact, there really is nothing wrong with Bitcoin, but there is lots of room for improvement. However, most improvements suggested have corresponding costs, and there is no consensus that the benefits outweigh the costs for many of the improvements.

Here are a few areas where improvements are likely possible:

The mining algorithm is only computation hard. It is not memory hard or decision hard.
Anonymity is limited by the inability to publish a receiving address without revealing how many coins are transferred to that address.
There is no good way to prune the block chain.
There is no good way to reverse a transaction or indicate acceptance of a transaction.
Transaction fees are not predictable long-term.
Mining pools have centralized the decision of which transactions to include and which chain to work on, defeating some of the protection diversified mining was supposed to provide.
There is no way to recover lost coins.
There is no good way to manage the currency if that turns out to be needed. For example, the block payout algorithm is all but fixed in stone but may make no sense in a decade.
There is no good way to pull coins out of the block chain such that they can be put back in.
A 51% attack can revert as much of the chain as desired, up to the last checkpoint.

My own opinion is that it's way too early to talk about Bitcoin 2.0. We don't know enough about what's really right and what's really wrong yet, and such efforts would actually work against broader adoption of crypto-currencies by reducing stability.


AntMiner C1 Manual:

  You must prepare your own ATX Power Supply. There are 4 PCI-e connectors for +12V DC
  input and all are required.

That either means:

The manual is right, and some of these are not 12V connectors. This seems unlikely.
The manual is wrong, and you need eight 6-pin PCI-e connectors.

  Is it possible to use two or more PSU's to power the miner?

It depends on how they designed the miner. Those connectors might join together inside the miner, which would mean that you'd want one power supply, or they might be two separate circuits, which would mean it would be more or less safe. Generally, you don't want to use two power supplies to power the same part, though. Can you take a picture of those connectors with the case off?

As for the power supply recommendation - power supplies with eight PCI-e are very expensive, primarily because nobody needs that many. I mean, a typical desktop computer is probably going to need one PCI-e connector. They do exist, though.

However, I would recommend getting two power supplies with four PCIe connectors. I suggest the Cooler Master G650M.

Oh, and the manual says this, which suggests that it's not water-cooled out of the box:

  Cooling kit is not included in C1, please read the instruction at www.bitmaintech.com to
  buy them.


Which Bitcoin escrow services are available - and reliable?

BTCrow.com, operator made quite a few posts about the service, Bitcoin Escrow Service - For safer bitcoin transactions


This is not possible.

The mnemonic words are an encoding of the entropy used in the seed, essentially. A 12 word seed has less entropy than a 24 word one, so you cannot get 24 words out of it. Similarly, you cannot get a 24 word seed to turn into a 12 word one.

Your best bet is to generate a new 24 word seed and move funds over.


Copying an old private key (from 2011) into Electrum: any risks?

No, Bitcoin Core (formerly known as Bitcoin-QT) is not a wallet, it is a full node software + wallet, so there are better software to use as a wallet. Sure, you can use Bitcoin Core, but you'll need to keep your Bitcoin Core connected to the internet for days to synchronize.

To summarize, you should use a wallet software (sure, Electrum!) to import (or sweep the funds of) the private key.

Note: A few satoshis is worthless. The median transaction fee is currently 110,740 satoshis. according to this.


How to withdraw dollars to Dwolla from Mt Gox

Apparently there is no way to know if a person has a pending Dwolla transfer for funds exiting Mt Gox.  The most confusing part about this is the pending status remains pending in Mt Gox for at least a day after Dwolla shows the transaction as having completed.

So I recommend waiting an extra day after Dwolla says the funds have transferred.  Otherwise the transfer will be canceled with no notification from Mt Gox or anyone else, and no reason is given for the transfer cancellation.  In fact, the only indication that the transfer is canceled when this happens is that the balance returns to the pre-transfer balance, and the funds never show up in Dwolla.

To Mt Gox's credit, Mt Gox did respond to my support requests.  However, getting a satisfactory response took almost two weeks of asking combined with plenty of trial and error with the Mt Gox withdraw system.


Does GDAX use its own wallet to send Bitcoin on my behalf?

Answers to your questions:

1. GDAX generate a new address for every transaction, they consider a generated address as used. The reason for a new address is to protect your privacy, so a third-party can not view all other transactions associated with your account by looking up an address you have used before.

2. and 3. When a GDAX user sends digital currency from their wallet, the address it comes "from" is one of GDAX's many hot wallet addresses. Any coins sent back to that address would be sent to GDAX, not your own wallet. So yes, kind of like shared wallet.


What is a stub from the lightning grpc documentation?

It turns out, it is grpc nomenclature. According to the documentation at grpc.io:

  gRPC users typically call these APIs on the client side and implement
  the corresponding API on the server side.

  ...

  On the client side, the client has a local object known as stub (for
  some languages, the preferred term is client) that implements the same
  methods as the service.

Which pretty much means using grpc on the client side looks like you're interacting with an object that performs the operations locally - when in reality that object ( known as a stub ) is making calls to the server asking it to perform certain actions.


Have Blockchain.info (intentionally) removed the option to directly exchange BCH into BTC/ETH?

Turns out that this was an issue with my home WiFi blocking some of Blockchain.info's API calls. Not sure why, mind you, but connecting to a different network allowed me to see those options again.


How do I track transactions made from my stolen phone

Sorry for your phone and your bitcoins, but unfortunately you can't find someone thanks to a wallet address. Wallet addresses are pseudonymous and any kind of personnal information (like IP address) are not stored on the blockchain.


Do private blockchains need consensus protocols?

TL;DR Yes, consensus protocols are always needed in distributed systems where there could be multiple writers to the same data. When it is possible for multiple participants to simultaneously update their local state, it can result in two inconsistent versions which can't be merged together into a globally consistent state.

In the context of a blockchain, publishing a block is analogous to reading and writing to balances, and we wish to enforce the constraint that every account balance >= 0 to prevent double spending.

Imagine that in the ledger state of block 4, I had 10 coins. Then in Branch A, I sent Alice 8 coins, but in Branch B I sent Bob 8 coins. If we tried to reconcile these two updates into one state then either I would have a balance of -6 coins, violating the balance >= 0 constraint, or coins would have to be illegally created.

Consensus algorithms are designed to ensure that each node has a valid state consistent with other nodes. As explained by CAP theorem, during a network partition a consensus algorithm must either make the service unavailable (Read Only) or allow for the two partitions to potentially become inconsistant. This means that when designing or choosing a consensus algorithm, one must decide between either consistency of the data (e.g. preventing double spend) or availability (e.g. making a transaction).

Nakamoto consensus prioritizes availability such that during a network partition it will continue to process transactions, and after a network partition, the global state will eventually be consistent. It quantifies each state's total proof of work to decide which state is the correct state. If our node had previously only observed branch A but then received the blocks from branch B, it would calculate the amount of work done in each state to decide which branch to accept. This means that during a network partition, the state is still available to be updated at the expense of it becoming inconsistent. After the network partition is resolved, the inconsistent states are resolved by reverting some of the updates and applying the ones that lead to a state with more proof of work.

Other consensus protocols such as the proof of stake variant used in Tendermint will prioritize consistency, meaning that during a network partition attempts to update the state may fail, making the service unavailable. To ensure consistent updates to the state (i.e. creating a block) nodes that controll at least 2/3 of the stake, must agree to a proposed block within a timeout period. If too little stake agrees to the proposed update, it will fail and revert and a new proposal will begin. This is somewhat comparable to a 2 phase commit, but differs in that it can tolerate the failure of nodes controlling up to 1/3 of the stake.

Even in a trusted environment where all machines are behaving correctly, inconsistent states can arise due to network latency, as asynchronous messaging is comparable to short-lived network partitions. Keeping state consistent becomes somewhat more difficult where we have more complex constraints to uphold (e.g. ensuring consistent smart contract execution)

Other non-blockchain private distributed systems, must make the same trade-off between Consistency and Availability, Google's BigTable maintains availability and replicates updates to other nodes making it eventually consistent throughout their data centers, for coordination within a BigTable cluster it relies on a fault tolerance lock distributed service named Chubby which uses paxos during leader elections. However, It seems that due to the reliability of Google's private WAN  (>99.9995% availability) and very accurate time-keeping, they have also built Spanner, the accuracy of their timestamps allow for updates to be ordered (or delayed if there is uncertainty about the order) such that an application's view of the data is consistent with the application's constraints and other invariants.

I highlight CAP theorem to explain how Nakamoto Consensus will always be available but subject to the eventual consistency, potentially allowing for a 51% attack. Other consensus protocols can provide finalization, but may not always be available opening them up to a system-halting DDoS attack. In the context of a private system, control of the hardware means that the distributed system can be virtually always available and shielded from DoS attacks, leading companies like Google to prefer the provision of consistency.


How resilient are Proof of Stake (PoS) mechanisms to brute force quantum computing attacks?

The main ways in which Bitcoin uses crypto algorithms are the following:

Hashing (2 x SHA256) of the block header for proof of work.
Hashing (SHA256 + RIPE160) of the public key to obtain an address (followed by base58 encoding but that's not crypto per se)
ECDSA to generate and validate signatures, allowing you spend an output.

The 2 first ways don't use ECDSA and so are not exposed to quantum computing attacks (assuming no mathematical breakthrough in prime factoring).

ECDSA signatures on the other hand may be breakable using quantum computing. So given an ECDSA public key and a quantum computer, one may be able to discover the private key.

However, public keys are only embedded in inputs when spending an output. The output itself only includes the hash of the public key, which is safe (one would need to break both ECDSA and hashing to recover the public key).

So to summarize, if a quantum computer was to be invented and assuming it could break the ECDSA asymetric encryption, the attacker could acquire all Bitcoins on addresses that have been reused (as the public key is known). Bitcoin addresses that have only been used once and proof of work should be safe. Same applies to proof of stake.


What is a brief summary of the ECB's report on virtual currency?

In the ECB's view,  (Bitcoin) can be used by business (criminals), customers (fraudsters) and savers (money launderers) to perform legal (illegal) activities, but lets ignore it until volume reaches a level where comparison with sovereign currencies reflects negatively on our reputation. The public will then expect us to regulate such digital (rogue) systems (schemes).


It is correct as written.  Accounts are just a grouping of addresses.  You generally create accounts with the getaccountaddress call.

This wiki page provides more detail on what accounts are all about.


How to send btc from multiple addresses to a single btc address?

If you were asking about creating transaction manually, you can do that by creating raw transactions using addresses (A, B, C) inputs.

You can set the fee by not spending the fee while creating the transaction.
so if you have 3 BTC you send 2.998 and just leave the rest, it will be considered as miners fee.

By default if you are using Bitcoin-core or any other wallet they are using required inputs to cover your payment, so you shouldn't worry about that.


Ok, I found the problem.

The thing is that you can not start mining prior to synchronizing with the network (getting all the blocks). The client is not telling you this and tells you that it is mining, when in fact it does not.

So there is no point in clicking start mining before you got everything. After you got all the blocks and pressing mining you can see the your speed here.


The rev*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk*.dat files which contain blocks.

Each block record consists of:

4 bytes: network magic (0xf9,0xbe,0xb4,0xd9)
4 bytes: size of the CBlockUndo record (LE32)
data_size bytes: CBlockUndo record
32 bytes: double-SHA256 of the serialized CBlockUndo record

A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.

A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.

A CTxInUndo record consists of:

varint: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO
varint: creating transaction's version [only when height > 0]
CompressedScript: spent UTXO's scriptPubKey
CompressedAmount: spent UTXO's nValue

Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.

For more information about the detailed encodings, see the comments in the Bitcoin Core source code: CompactSize, VarInt, CompressedScript, and CompressedAmount.


How can 6.10 ₿ be the average value of a Bitcoin transaction (lately)?

This is normal. Here you can see a chart of average transacted value every day: https://blockchair.com/bitcoin/charts/average-transaction-amount-btc
There are 2 things that contribute to this:

The very large transactions skewing the numbers. This becomes more apparent if you take a look at the median transaction values, which are around the 0.02-0.03 BTC range, closer to your expected value: https://blockchair.com/bitcoin/charts/median-transaction-amount-btc

The fact that many transactions aren't just sending money from one person to another person, but in most cases, includes change (sending money back to the sender's own wallet), and batched transactions (a single transaction that sends money to multiple people, often used by exchanges to process withdrawals while saving money on fees).


Is it cryptographically possible to have aggregate signature schemes that can improve privacy in UTXO consolidation?

Yes, I believe that the accumulator constructions as described here are a good candidate. The same idea applied to Bitcoin is implemented by Tadge Dryja here


Accepting Bitcoin payments without the full blockchain or third party APIs?

If you don't want to run a node or use any 3rd party APIs you can use a library since you only want to accept payments.

Use an extended public key from one of your wallets, and generate new addresses from the HD xpub using a library. When a user pays it will show up in your Phone/PC wallet.

For example with Bitcore library it would be:

var bitcore = require("bitcore-lib");

var pub = new bitcore.HDPublicKey('xpubMyHDPublicKey');
var derivedHdPublicKey = pub.derive('m/0/1');
//increment up the keychain m/0/2, m/0/3, etc each order
var derivedPublicKey = derivedHdPublicKey.publicKey;
var address = new bitcore.Address(derivedPublicKey);
console.log(address);

Then just keep track of orders and addresses on your server database.


You'll want to save the seed phrase mnemonic (likely 12-24 words long) that the wallet gives you when you first start it up. Doing so is very important!

If Bitcoin.com disappears tomorrow, you'll be able to input that seed phrase into any other compatible piece software. Many wallets use the same key derivation scheme.


Mining bitcoin using LAN and one computer with internet access

It certainly is, you could for example install the stratum mining proxy (assuming that the pool you are mining for supports stratum). You would install the mining proxy on the computer with network access and then configure the miners to use the proxy instead of directly going to the pool itself.

Of course this is just one of many options. Other options include creating a reverse HTTP proxy on the computer with internet access, as the getwork protocol uses HTTP underneath. Also possible would be to tunnel a given port directly to the pool using SSH for example. But I think the mining proxy is the easiest option, and allows for legacy mining software to use the more efficient stratum protocol as an added bonus.


what's the principle of sending money and receiving money? who do the work to put money into account？

An individual or merchant requesting payment will generally want to obtain a bitcoin address specific for that transaction.  When done manually, this is obtained from the Bitcoin-Qt client by clicking "Receive".  A merchant would have software that would query the Bitcoin.org client to obtain the address. An EWallet provider will provide for you this address.

The concept you possibly are misunderstanding is like how with a bank account, the account is assigned to an individual or organization before payment is transferred.

With Bitcoin, the client uses math to create the private key (and from that determine the Bitcoin address).  So there doesn't need to be some master registry where Bitcoin addresses are stored.  The person's client simply holds the keys necessary to spend any funds received by an address.

So that answers your second question -- bitcoin never really exist "in your account" but instead if you have the private key for an address, you can spend any funds received by that address.  Every node performs verification of your transaction and won't accept a transaction in which you try to spend funds that aren't yours.   Nodes that are mining will make these transactions permanent by including them in a sequence of data blocks -- which is named the blockchain.

So there are no people doing work, and instead there is simply an electronic communications protocol that is being employed.


Why do miners need a nonce if the timestamp changes the hash of the block?

Is it because they're mining too fast for the timestamp to change?

Precisely - even a relatively slow CPU can hash several hundred headers every second. Modern day ASICs can hit 100+ terahashes per second - ripping through the entire nonce space several times over.

Moreover, the timestamp is also a 4 byte value - miners do use it, in conjunction with the nonce, merkle root, and block version to create a much larger search space. Even so, the majority of combinations of all of these do not result in valid blocks.


Ripple: How to monitor multiple accounts reliably and effectively?

I'm not sure a large code paste is the best way to get your example across (I'm unfamiliar with the library/API you're using for example). Assuming it's correct to summarize that you are looping, repeatedly doing account_tx RPC calls with at most a ten second delay; then that's not efficient even for a small number of accounts.

For a small-ish number of accounts, I'd recommend doing something like your loop only on restart to catchup from a last known ledger you've processed. (For example, after restarting your monitoring after an outage or disconnect). Once caught up it's better to use the subscribe RPC with the set of Ripple accounts you're interested in. The server will send you a notification anytime any transaction touches any of the accounts you list. This avoids polling and is far more efficient, especially during periods where the accounts are idle. (I'm only familar with using subscribe over a websocket, and it works very well for this even over days; I don't know what library support for this is like).

Once you go beyond a certain threshold of accounts you are trying to watch, especially if they are very active accounts, it may be easier to use the subscribe RPC to subscribe to all transactions and filter those for just the ones effecting the accounts you're interested in. Also, at that point it may become a good idea to do such queries against your own locally running rippled rather than rely on a public Ripple server.

The point at which it's best to switch from subscribing to a list of accounts versus subscribing to all transactions is unclear to me. For starters, there may be a limit to the number of accounts you can specify in a subscribe call; if so perhaps modify a locally running rippled to remove any such limit and have it do the filtering may be appropriate.


With Ripple, is it possible to have XRP IOUs?

We debated how to handle XRP IOUs during the design. Ultimately, we decided not to have any official support of them because of the potential for user confusion. However, we did reserve the currency name "XRR" for IOUs denominated in XRPs. There is no built in mechanism to pay them off with XRPs, but it's not difficult to place a 1-to-1 exchange offer. Such functionality might be added in the future.

We also debated allowing IOUs to pay transaction fees directly, rather than having to first exchange them for XRP. We couldn't see any advantage and there are some significant disadvantages in addition to the added complexity. The big one is the exchange rate might change such that the transaction can't claim a fee and we wouldn't discover that until the transaction was processed. There was a fear someone could bombard the network with such transactions and cause high load at no cost. Instead, we decided to try to keep transaction fees so low that there would be no reason to care.


The best way to switch to Electrum is to send all the bitcoins you have on your old wallet to one of the addresses on your Electrum wallet. This way you'll have all your bitcoins secured with your seed.

You could import the private keys from your old client, but you will have to keep a backup of those keys separately as they won't become part of your Electrum seed.

http://electrum.org/tutorials.html#switching-to-electrum


Start the client with the -reindex command-line option.


Ledger Nano X stuck in loop before being initialized

When pressing both buttons, it appears there is some kind of "long click" that does different things than a quick press of both buttons.  Not knowing that I was consistently doing long click which confused the Nano X.  Once I figured out that a quick tap of both buttons was all that was needed to select an item, thing started getting more sane.

Having done a long click once at the very beginning, put me into that special menu mentioned above and once I was there I was lost.  However, I let the device timeout and go to sleep, then using quick/short double presses only, everything worked as per documentation.


I am hosting a webvisualization that depends on the websocket API from blockchain.info. The API stopped working at exactly 16:40:45 GMT yesterday (march 1st) for me.

This API has gone down in the past, let's hope it goes up fast.

EDIT: for me it is working again (since 13:50:14 GMT).


How to restore from backup of Android Bitcoin Wallet

The best way to restore a backup file is always to use the same app used for creating the backup. In other words, install the app again, then use Options > Safety > Restore wallet.


I don't think that's a rendering. I think that's an actual copper coin with a bitcoin/circuitry theme.

Googling the text on the back, "AOCS APPROVED MJB 2013," finds this site, which gives the designer's name, Mick Bruce. Presumably "MJB" is his initials.

Googling that turns up this thread on BitcoinTalk, which is pretty similar to your coin.

I can't turn up a 3d model, but the designer, Mick Bruce, might have it. You might be able to contact him via the email in this thread, or by this onename.


Why to mine with a high difficult on PPLNS

The server will reject all shares that are below the difficulty it specified in your getwork request.

Reasons for the server to lower the difficulty of accepted shares:

Less variance for users

Reasons for the server to raise the difficulty of accepted shares:

Lowers bandwidth usage

Something from 4 to 10000 is about right.


Why isn't 'classic' Multi-Paxos Byzantine Consensus used for public Blockchains?

Nakamoto Consensus has some properties that are superior to BFT algorithms. (It also has some properties that are inferior, but that's another story).

First, BFT algorithms assume a central authority picks who the participants are. NC, on the other hand, allows anyone to attempt to win the next round.

Second, BFT algorithms generally require 2/3 + 1 (e.g. 67%) of the participants are honest. NC sets a lower threshold of 1/2 + 1 (e.g. 51%). That's because NC's PoW prevents a node from broadcasting two messages at once.

Finally, NC has the interesting attribute that the moment a miner "wins", they also simultaneously choose the transactions they are going to include on the block. This means there is no window of opportunity for an attacker to attempt to influence the winning miner to break the rules.

Note that Paxos is not a BFT algorithm. Paxos solves for stop-fail failures. The worst a node can do is stop working. Paxos does not solve for "byzantine" failures, where a node can try to say two different things.


How is crypto being priced at introduction?

Here's the way it works in theory (and in fact how it worked for bitcoin):

0) initially there's no market, no trades, but there is a cost of producing the item. You might ask why anyone would make something that costs money but can't be sold - nerd enthusiasm

1) trade offers at specific prices are made. These were based on the cost to produce. Offers are not accepted yet. At this stage you could say the market exists.

2) the first trade offers match and execute. At this time the exchange rate is 'discovered' (at least the first guess at it anyway). Not sure if it was the first, but the most famous early price defining transaction for bitcoin was the trade of 2 family sized pizzas for 10000 bitcoins. The pizzas were priced in USD so the trade discovered the BTCUSD pair exchange rate. The 10000 was loosely based on electricity cost to produce the bitcoins.

In the current environment things work the same - people make offers and the market discovers the best price.

To the first part of your question, you can now see that the 'growth' is anywhere from undefined, thru infinity, down to some discovered value. It's pretty meaningless to apply it to early markets.

You ask if all coins are 'available at the introductory price' but the market price is dynamic and is determined by the demand and availability. Sometimes there are offers made to supply a fixed number of items at a specified exchange rate, but this is before a market is open.


Regarding Mnemonic Code words and salt key

Third Parties should extend your mnemonic phrase with your passphrase else they will get a different wallet with different addresses.

Electrum and some other wallets call the passphrase a "seed extension" or "mnemonic extension".

Third parties should have an option to extend mnemonic phrase with your passphrase, It's a weird idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason, many wallets make it possible to encrypt a mnemonic phrase with a password.

Take a look at this open-source project, you can import play around with any mnemonic phrase and extend it with your passphrase and see the changes


Thank you for answer! :) Could you tell one more thing? How can I get
  proper output script? I thought that I have all information needed to
  count in this transaction. If I have for example this transaction link
  , what should I do? What scriptPubKey shoud I use?

Dont get scared by the wall of Text following, I just want to make it as understandable as I can:

Give this TX-Data:

{
  "txid": "1ea183203c2a2b8db9a84b0d90bfc0b072f0484ec6536b95f69733ae251a3288",
  "version": 2,
  "locktime": 0,
  "tx-comment": "",
  "vin": [
    {
      "txid": "8094704e00978c58f3d51d6c44b460af6c04dac86ef1b79c202208e5c65d0a50",
      "vout": 0,
      "scriptSig": {
        "asm": "304402205474316eb33e1c61e4fa099a0a99d9448e0ffa380b1da8d894e0101fd0eecf7e02206b4bd7498894eb626b1ab1945ddff720b240e8d992e756ff9711a7390951d8a501 03e1cc71fe608be3fa01247476d6fbb758c14af7fa269b151e202f4a2e5a530022",
        "hex": "47304402205474316eb33e1c61e4fa099a0a99d9448e0ffa380b1da8d894e0101fd0eecf7e02206b4bd7498894eb626b1ab1945ddff720b240e8d992e756ff9711a7390951d8a5012103e1cc71fe608be3fa01247476d6fbb758c14af7fa269b151e202f4a2e5a530022"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 1.3491183,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 9aa813b6983a609ebb5992408457dbb814824124 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9149aa813b6983a609ebb5992408457dbb81482412488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FKvrsYB5dR2xSW1ujUXq7RLdiUxoZHEH58"
        ]
      }
    },
    {
      "value": 1.59661273,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 3ea405431679a7d51fb5da6106cb91f4a1d066ec OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9143ea405431679a7d51fb5da6106cb91f4a1d066ec88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FBYKr3SGVWMrbHngSGVua1LiCN2GYQV8Lp"
        ]
      }
    }
  ]
}

This Transaction got one input:

 "vin": [
        {
          "txid": "8094704e00978c58f3d51d6c44b460af6c04dac86ef1b79c202208e5c65d0a50",
          "vout": 0,
          "scriptSig": {
            "asm": "304402205474316eb33e1c61e4fa099a0a99d9448e0ffa380b1da8d894e0101fd0eecf7e02206b4bd7498894eb626b1ab1945ddff720b240e8d992e756ff9711a7390951d8a501 03e1cc71fe608be3fa01247476d6fbb758c14af7fa269b151e202f4a2e5a530022",
            "hex": "47304402205474316eb33e1c61e4fa099a0a99d9448e0ffa380b1da8d894e0101fd0eecf7e02206b4bd7498894eb626b1ab1945ddff720b240e8d992e756ff9711a7390951d8a5012103e1cc71fe608be3fa01247476d6fbb758c14af7fa269b151e202f4a2e5a530022"
          },
          "sequence": 4294967295
        }
      ]

This input is refering to an output from a previous transaction:

"txid": "8094704e00978c58f3d51d6c44b460af6c04dac86ef1b79c202208e5c65d0a50"
"vout": 0

This is the point where you get your scriptPubKey from. Input:

"vout": [
    {
      "value": 3.04573103,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a0207d9ea622db7f63b70223ba4dea67c260a91b OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a0207d9ea622db7f63b70223ba4dea67c260a91b88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FLRnVzFCvGbKEpbjsFBSRejBHEcpbKScAe"
        ]
      }
    },
    {
      "value": 29.93357942,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 5eecec983a2105c049b4d1c1a43287ee07bd075f OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9145eecec983a2105c049b4d1c1a43287ee07bd075f88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FEV2oce6qUAq9zYfJeBMVZTk6qeJfvkQ7n"
        ]
      }
    }
  ]

There are two outputs. The right one is:

"n": 0

because the reference was:

"vout": 0

And here is the Script you need:

"asm": "OP_DUP OP_HASH160 a0207d9ea622db7f63b70223ba4dea67c260a91b OP_EQUALVERIFY OP_CHECKSIG"
"hex": "76a914a0207d9ea622db7f63b70223ba4dea67c260a91b88ac"

Back to your original Transaction and its outputs:

"vout": [
    {
      "value": 1.3491183,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 9aa813b6983a609ebb5992408457dbb814824124 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9149aa813b6983a609ebb5992408457dbb81482412488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FKvrsYB5dR2xSW1ujUXq7RLdiUxoZHEH58"
        ]
      }
    },
    {
      "value": 1.59661273,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 3ea405431679a7d51fb5da6106cb91f4a1d066ec OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9143ea405431679a7d51fb5da6106cb91f4a1d066ec88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "FBYKr3SGVWMrbHngSGVua1LiCN2GYQV8Lp"
        ]
      }
    }
  ]

Those are not needed for checking the inputs of your transaction. They will be needed for the next Transaction spending your coins from this transaction.

I hope I dont confuse you, and if i did we can propably use chat or so.


As long as the transaction is in the network (it has been transmitted without double spends), you can access your bitcoins with the private key from any client, be it Standard Client, blockchain.info or anything else. Your money is not stored in your wallet, but in the Bitcoin Network - only the private key that lets you access that money is stored in the wallet file.


Is there a convention for how to order UTXOs in a transaction with multiple inputs?

The convention is to have the outputs in random order. This is specifically done in an effort to conceal which output is the change output. The change is by default sent to a new address that is owned by the sender, and as such has no history associated with it.

The majority of bitcoin's code is actually c++. Here is a link to the relevant transaction creation code, maybe there are a few comments that could point you in the right direction.


what is the relationship between the blockchain size and the transaction volume on the network?

Well, there are upper per-block size limits (about 500KB per block) based on the currently implemented protocol.  So max levels might be 5x or 10X current levels.

When those levels get hit, then it will be levels of fees that determine transaction volumes, and the many microtransactions seen today will no longer be justifiable.


How do exchange services distinguish who sent to them?

Exchanges generate a new address for each user when a user wants to deposit, so when they receive a deposit to a specific address, they know who to credit the deposit to.

Since Bitcoin does not use accounts, there is no need for the exchange to consolidate their received Bitcoin. They can simply spend from multiple addresses when they want to send Bitcoin to someone, e.g. for a withdraw.


Can the Lightning Network work and live independently from Bitcoin?

No, not without any transactions. The Lightning Network is based on so called channels between 2 users.

The creation of this channel has to be broadcasted to the blockchain (and another transaction is needed to close it again).

While creating the channel, you've also to put some BTC into the channel, which then can be transferred between both ends.

To have an example here:

A and B are creating a channel between each other. A creates the channel and puts 1 BTC into it, B doesn't add any BTC to it. This creation requires a transaction on the regular BTC blockchain.

Once the channel exists, A sends 0.5 BTC to B (maximum is 1 BTC as this was the ammount the channel was created with). A few days later B sends 0.1 back to A and closes the channel.

Now the transaction to close the channel will contain: Transfer 0.4 BTC from A to B (as this is the final balance), and only this transaction will be executed.

No matter how many transactions will be performed between A and B, only the final balance will be mined into the chain.

But that's not the only trick with the lightning network. If A has a channel with B and B another channel with C, A can also send BTC to C (over B) without the need to have a separate channel between A and C, but only the minimum BTC of channel A->B and B->C is transferrable. So if A -> B has a cannel value of 500 BTC, but B->C has only 1 BTC volume, A can only send a max. of 1 BTC from A to C.

While transactions within those channels are free of any transactions on the blockchain, opening and closing will require a transaction. Closing is also required to receive the BTCs initially "stored" in the channel.

Hope this clarifies a little bit how the LN technically works


Why do other miners check block validity along with proof of work?

Miners are incentivized to validate both transactions and proof of work because if they start mining a new block on top of an invalid block any block they successfully mine won't be accepted by the full nodes and other miners on the network. Therefore the energy expended on finding a proof of work will be wasted. (Each block header refers to the hash of the previous block and so one single invalid transaction in a previous block would make all blocks mined on top of it invalid also.)
In addition, miners have made large investments in hardware (ASICs) and so their long term interests are aligned with the network. Even if all the miners on the network colluded to include an invalid transaction in a block, not only would some full nodes reject it but it would also be an attack on the long term viability of Bitcoin. Bitcoin only works if invalid transactions are not included in the blockchain.


Why am I unable to post two transactions (the second from the change address of the first) in the same block?

I think my issue was that I was accidentally trying to spend the output from my first transaction (which had insufficient funds for both the given fee and the given amount of change) instead of the output I was getting from the faucet, which I meant to spend. I haven't written a good solution to this problem yet, but I got around it in this simplified instance by building both transactions before propagating either.

Here is one of the transactions, and here is the other.

Here is the horrible code that made them:

var assert = require('assert'),
    bitcoin = require('bitcoinjs-lib'),
    blockchain = new (require('cb-helloblock'))('testnet'),
    dynamicKey,
    dynamicChangeKey,
    transactions = [],
    dataPoints = [],
    dataScripts = [];

connect = function (callback) {
    dynamicKey = bitcoin.ECKey.makeRandom();
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    buildTransaction(dynamicKey, dynamicChangeKey,
            "Connecting to blockchain...", callback);
};

message = function (callback) {
    dynamicKey = dynamicChangeKey; //bitcoin.ECKey.makeRandom();
    dynamicChangeKey = bitcoin.ECKey.makeRandom();

    buildTransaction(dynamicKey, dynamicChangeKey, "Posted to blockchain.",
            callback);
};

buildTransaction = function (key, changeKey, arbitraryData, callback) {
    var address = key.pub.getAddress(bitcoin.networks.testnet).
            toString();

    blockchain.addresses.__faucetWithdraw(address, 2e4, function (err) {

        if (err) return callback(err);

        blockchain.addresses.unspents(address, function (err, unspents) {
            var tx,
                data,
                dataScript,
                unspent,
                txBuilt;

            if (err) return callback(err);

            tx = new bitcoin.TransactionBuilder();
            data = new Buffer(arbitraryData.toString());
            dataScript = bitcoin.scripts.nullDataOutput(data);
            unspent = unspents.pop();

            tx.addInput(unspent.txId, unspent.vout);
            tx.addOutput(dataScript, 1000);
            tx.addOutput(changeKey.pub.getAddress(bitcoin.networks.
                    testnet).toString(), 1000);
            tx.sign(0, key);
            txBuilt = tx.build();

            dataPoints.push(data);
            dataScripts.push(dataScript);
            transactions.push(txBuilt);

            callback();
        });
    });
};

propogateTransaction = function (data, dataScript, txBuilt, callback) {

    blockchain.transactions.propagate(txBuilt.toHex(), function (err) {

        if (err) return callback(err);

        // check that the message was propagated
        blockchain.transactions.get(txBuilt.getId(), function (err,
               transaction) {
            var actual,
                dataScript2,
                data2;

            if (err) return callback(err);

            actual = bitcoin.Transaction.fromHex(transaction.txHex);
            dataScript2 = actual.outs[0].script;
            data2 = dataScript2.chunks[1];

            assert.deepEqual(dataScript, dataScript2);
            assert.deepEqual(data, data2);

            callback();
        });
    });
};

propogateBothTransactions = function () {
    propogateTransaction(dataPoints[0], dataScripts[0], transactions[0],
            propogateTransaction.bind(undefined, dataPoints[1], dataScripts[1],
            transactions[1], log));
};

log = function (value) {
    console.log(value);
};

connect(message.bind(undefined, propogateBothTransactions));


How can Open Transactions benefit Bitcoin?

Market exchange

OT includes bid/ask markets, allowing for trade between assets. And unlike most exchanges, the voting pools feature makes it impossible for the server to steal the coins.

Untraceable transactions

OT incorporates Chaumian blinding (untraceable cash), meaning it can provide anonymity and untraceability, similar to what the Bitcoin community strives for with existing mix services. (Bitcoin by itself is publicly-audit-able, which is a strength, but is also the opposite of untraceable. Its benefit is censorship-resistance, not untraceability, which can be added separately using OT.)

Instant settlement

OT has instant finality of settlement (instead of waiting 10 minutes to an hour for a transaction to clear.) This can be useful where merchants and and shopping carts are involved.

Micro-transactions

Micro-transactions will be more feasible on transaction servers than they would be on the blockchain.

Cash streaming protocols

Cash streaming protocols, in general, should become more prevalent and help to solve issues of resource allocation on mesh networks, anonymous networks, etc. Virtual Tahoe LAFS hosting and so on will eventually become more available, whether via OT or some similar system. (This would help protect the lives of Syrian bloggers murdered by snipers, and the lives of Chinese bloggers unjustly imprisoned to decades+ of hard labor--and to protect the anonymity of Mexicans who otherwise risk being disemboweled and strung from a bridge when following a "Real Names" policy.)

Operates securely on low-trust servers

OT cannot lie on your receipt. It cannot change your balance or forge any of your transactions. (Bitcoin also is like this, but it's still worth mentioning.) Combined with an auditing protocol, this makes it possible to run low-trust servers.

No transaction history

On OT, unlike most other systems, and unlike the blockchain, you will be able to prove which instruments are valid, and which transactions are cleared, without storing any transaction history, as long as you keep your last signed receipt. This is useful to all parties, and also reduces the cost of running a transaction server.

Full range of financial instruments

OT supports a full gamut of financial instruments, including cheques, transfers, cash, cashier's cheques, receipts, recurring payments, market offers and trades, and smart contracts (scriptable clauses - write your own.) You will have to decide for yourself how to best use these capabilities.

You could use OT to write a market exchange, or online wallet or personal wallet. (Of course these exist already, but I'm just saying...)

Smart contracts

OT makes it possible to create custom-scripted agreements between parties, to be executed on the server side.

You could use OT to offer escrow services. You could devise your own escrow contract in script form, and then OT will process it.

Client-side scripting

OT also supports client-side scripting, meaning that people can combine "Unix scripting" with "financial transactions". The possibilities are endless, but that part is really up to the developer community.

You could use OT to build a digital ticketing system, printing out tickets with QR codes or whatever.

In-game representations of real-world financial environments

You could use OT to build a full financial transaction system into an online game or virtual universe. (Gold duplication can get to be a real issue on games.) People on the game would be able to open accounts, withdraw and deposit cash, write cheques, trade on markets, just like people in real life. People would even be able to issue their own currencies, and trade in basket currencies.

Protection against online wallet fraud

At some point OT will support Bitcoin voting pools, meaning it would be impossible for any single server to just disappear with your Bitcoins. (A problem currently endemic to the Bitcoin world.) This will be a protocol between OT servers based on existing features in the Bitcoin script language (like multi-sign.)

This capability goes beyond mere auditing or proof-of-reserves, since it actually prevents a server--or a malicious employee, or a hacker--from stealing the coins.


The most capable working implementation for extending BIP 38 to altcoins (having strong Bitcoin heritage) is provided by bitcoin-explorer's (bx) Key Encryption Commands (with working examples applied to Dash) that supports both BIP 38 modes:
1. AES256Encrypt, AES256Decrypt - a paper wallet use case
2. EC Multiply - a Casascius use case
A backwardly compatible Proposal and a Table are provided to have deterministic leading base58check encoded characters, apart from the "6P" allocated to Bitcoin, to distinguish BIP 38 encrypted keys from those belonging to different altcoin blockchains. See the BIP 44 Altcoin Version Mapping Table to apply proposed BIP 38 extension to support cryptocurrencies other than Bitcoin (BTC). Also worth examining the BIP 38 Security Considerations wiki page.


What’s the purpose of checking for input overflow?

It appears to largely be just a belt-and-suspenders check. As you say, it is unnecessary to do this check. However it doesn't hurt to have this check in there. At worst, it just adds a few nanoseconds to verification time. At best, it will catch some serious bugs.

Given that this is consensus related, it does not hurt to have extra checks that are theoretically unnecessary. They will prevent errors in cases where some edge case occurs. In this case, it was possible for an input with negative value to be spent and thus this check would come into play. That would occur if someone updated their node following the block with the bad transaction, but did not rollback their blockchain. If the owner of the negative output had spent it, this check would have prevented the node from accepting the transaction.


Can old wallets redeem segwit outputs it receives? If so how?

So from this, it naturally follows that old non-segwit wallets should not be able to spend segwit transactions.

That is correct. A wallet that does not know anything about segwit will be unable to construct a valid transaction input that spends a segwit output.

However, the premise of the question

  when an old wallet receives a segwit transaction meant for it

doesn't make sense either. If a wallet does not know about segwit, it will never construct a segwit address to give out. So, by definition, there cannot be any segwit output meant for it.

It is always the receiver who decides what exact outputs to accept money on - and this is what gets encoded into an address.


Desperate need of help - Face ID stopped working on blockchain wallet app and I don't remember password

Most of the issues you're encountering are limited to the proprietary processes used by the blockchain app you are using, and only their support will be able to navigate you through them. Concepts such as face ID, wallet ID, etc. are not standardized by the bitcoin implementations, and vary from provider to provider.

If you're lucky, when Face ID is disabled, whatever scheme they used to decrypt the wallet via Face ID is not deleted, and may be recoverable with someone from the company helping you. However, a well designed wallet would likely remove any secret used to grant access via secondary authentication such as Face ID if the authentication's validity was in question, and fallback to a password based decryption instead.

From a general bitcoin perspective, without the backup seed words, you essentially have no bitcoin, unless you are able to get someone who knows the app's processes to help you recover any information that may remain. Even after that, it is highly likely that the information is encrypted in a manner which prevents anyone from accessing it without the password.


How to obfuscate public IP of Mining pool?

The Stratum Mining Protocol ist not based on HTTP, so you will not be able to mediate it through Cloudflare or a similar service, unfortunately. Cloudflare and the like are designed for web content as in web pages.


Lightning, multiple channels to the same node

Not all implementations support multiple channels between two nodes. That is why I would advise against that practice. Also I do not really see an advantage of having two channels. We don't have Atomic multipath routing yet so in general it makes more sense to have larger channels.

Only counter argument I see is that one channel can only have 483 htlcs stimulaniously. So imagine you are an extremely well doing routing node and have a channel to another node of that kind you might want to go beyond 483 htlcs and open up another channel. I would however doubt that this situation will come up in real life as you would probably already have more than 1 lightning node running in such a situation.


Why can't P2PKH's scriptPubKey be shortened to only OP_CHECKSIG?

The script achieves two things:

Ensures the provided public key matches the provided signature
Ensures the provided public key leads to the same address script the utxo was locked with.

A P2PKH script contains the hash of the public key. When you spend the coins, you provide a public key, and a signature.

First, the script duplicates the provided public key, then runs it through hash160, and compares the output to the hash embedded in the locking script.

Once that check passes, it validates the provided signature against the same public key. This ensures that the signature comes from the same key that was used to generate the address.


Generating P2WSH addresses | Is there a standard WitnessScript?

It is 0 and a 32-byte push of Sha256 of the scriptPubKey (which is the script you use to generate the address). You can find an example here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh
The Python example you linked uses WP2PSH as WP2PKH. You can see the how WP2PKH works here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh


Recieve Bitcoin value notifications on iPhone

The Bitcoin Ticker app seems like it would fit your needs nicely.


There are several hard-coded DNS seeds, which work AFAIK as a DNS round-robin to provide connection to several random nodes.

Once initially connected to nodes, peer discovery is automatic and your node could easily learn about the entire network through just a few connected nodes.

There is a slight chance that a malicious ISP could hijack DNS or for that matter, all Bitcoin traffic, either preventing peer discovery or alternatively providing false or limited results. This has already been asked elsewhere. Provided you are able to connect to just a few well-connected nodes on main-net everything will work as expected.


How can I make Zap synchronize with the Bitcoin network?

To run the wallets you mentioned, you will need to also run a bitcoin node (bitcoind or btcd, most likely), and an lndnode as well. This information is listed in the README files on the pages you linked to.

I believe there are lightning network wallets that work without a local full node, but I don’t have experience with one so you’ll have to dig a bit to find one that works for you. NOTE: without running a node on your machine, you will be trusting someone else’s node in order to use the lightning network.


Can a core wallet coinbase-transaction (generation transaction) be moved intact to a net new core wallet?

No. Any transaction that you make will make it "not whole". i.e. the "coins" move to a different output. You cannot move any coins without making a transaction.


I find http://bitcoincharts.com to be of high quality.


How to get paid providing full node services?

Presently, you cannot.

According to BitNodes, as of this writing there are over 5000 full nodes on the network, all of them providing this service for free.  This certainly seems to be sufficient for everyone who wants to use it.  So nobody is going to pay you money for a service they can have for free.  The effective market value of your services is zero.

It is possible that someday, as the cost of running a full node rises, there may not be enough people running free full nodes to satisfy the demand.  In that case, the market value of this service may increase above zero, and you might be able to get people to pay to use your node.  Note that if this happens, you'll probably also have to pay other nodes for the privilege of sharing their data with your customers, and getting them to help distribute data from your customers.  But at this point, this is pure speculation.


To be more energy efficient, wouldn't be a consensual fork - right now - without the reward of new mined btc for each block helpful?

I would assume that the transactions fees would stay or converge to be very low levels, because every miner has always an incentive to add any transaction with a positive fee.

Block space is finite, so users are bidding for their position within the next block. Miners will always choose the transactions which have the highest feerate because it makes their income the highest. Today the fee rate often makes up a significant ($100k+ USD) portion of the total block reward.

https://mempool.space/

How the transactions fees will evolve would be quite crucial the get the miners activity down (and their energy consumption).

Mining activity would reduce naturally if there was less reward, but there's no opportunity for changing core principles of Bitcoin like this.
As a valuable currency Bitcoin needs to be predictable and justifiable, if the rules dramatically changed it would make a fairly lousy currency. You wouldn't be able to invest in mining hardware for example, if you couldn't model even the base income a couple of months into the future. Making even small changes to the economics of the system opens the floodgates for others. ultimately.

For sure there are some cryptocurrencies which reached that state (of no mining new coins). How did the transaction fees evolve after mining the last coin?

There's no useful comparisons to be made, nothing has the scale, maturity, and properties of Bitcoin.


this happens sometimes on many exchanges. i have seen this also on poloniex and bittrex for other cryptocurrensies. this is usually a normal procedure. in a few days you should be able to deposit/withdraw your funds again.


How to import private key on testnet and verify balance of wallet?

I wrote this python library since pybitcointools is no longer supported. You can check testnet balances like this (it pulls data from blockchain.info)

import os
os.environ['CRYPTOTOOLS_NETWORK'] = 'test'

from btctools import Address

address = Address('n2NGrooSecJaiD6ssp4YqFoj9eZ7GrCJ66')

>>> address.balance()
0.55


How to connect to a public node through json RPC?

Not all nodes will have the JSON-RPC enabled, and especially without private credentials. You will probably find a block explorer API much more accessible, because they are built to handle public traffic. There are many blockchain explorers online that have public apis, they are easy to find.


How many bitcoins do bitcoin faucets give away per day on average?

Bitcoin Faucets were useful once upon a time, when 10000 BTC still bought you only a single pizza (and even by then, they were starting to die out).

Presently, you will earn next to nothing with faucets - in fact, most faucet websites usually make you earn in DOGE or other coins with much lower values, as the time taken to earn enough BTC to be able to withdraw without losing it all to tx fees is far too large.

If your goal is to acquire BTC cheaply, your best bet would be to get a regular job and simply buy it - even $10 a day would buy you more BTC than any faucet would give to you in months.


Is it possible to link one single LN node to Bitcoin addresses?

If a channel is announced a multisig output - which encodes the capacity of a channel - is linked to two nodes on the lightning network. This mutltisig output is obviously onchain and can be seen as onchain funds.

This does not mean that we know directly who funded the channel and how the funds are split between nodes in the commitment / settlement transaction.

However the funding transaction was consuming some other outputs. They might have come from the settlement transaction of another channel. This links two funding transactions. The node that takes part in both payment channels is the one who funded the second channel. Currently lightning nodes reuse outputs and do not mix / coinjoin them. Thus the analysis is rather straight forward.

However it seems that if nodes never reuse outputs and if channels never close it will be much harder to link funds to a single node.


What are the arguments for and against using the Lightning Network with Bitcoin?

pros:

Lower Transactions Fees
More Transactions per second / block possible
micropayments possible
payments are more private than on bitcoin

cons:

funds are on a hot wallet
(at least currently) node needs to be online all the time
still somewhat buggy
(at least currently) only small amounts can be routed


Does MtGox charge commission in USD or in BTC?

Mtgox charges the fee from whatever you're buying.

So if you buy 100 btc for however many USD, you'll buy the BTC, then you'll be charged 0.6% of your 100btc as fee.

If you buy 100 USD for however many BTC (i.e., sell some btc), you'll get your USD, and will be charged 0.6% of your 100USD as fee.

Edit: This is actually configurable. If you go to the mtgox settings page in your account, you can set the fee to be taken out either as above (default), or out of your USD balance always.


You decode them in exactly the same way that you decode a transaction. They are perfectly valid transactions and a decoder should be able to decode them properly and get meaningful data out of them. The reason they look weird is because every part of the transaction is randomly generated so the fields do not necessarily contain data that you expect (e.g. the version number is randomly generated instead of the standard 01000000 or 02000000).


Bittrex websockets: How to get the order history?

So ...it turns out from correspondence with a Bittrex developer that it is currently not possible to get the order history via websockets.

One has to revert to the "normal" public API for this: https://bittrex.com/home/api


There's no current way to check the Amazon gift card balance without actually depositing the gift card into your account.

See this post from purse.io for more details.


How can I reproduce the same binary as bitcoin.org or bitcoincore.org?

The challenge with creating reproducible builds is that you need to ensure that the build process matches exactly across different operating systems and different architectures. Bitcoin uses Gitian, a deterministic build process to achieve that.
Bitcoin Core provides the configuration and build instructions for various operating systems in the /contrib/gitian-descriptors directory in the Bitcoin source code.
For Linux you would use this gitian-linux.yml.


Why keys generated in Bitcoin Core mismatch that from online generators despite using the same seed?

I want to know why the two tools are giving different results

Bitcoin Core uses hardened derivation to derive child private keys from the master private key. You can check the embedded link for more details, but in summary it means that the software uses parent private keys within the hash function to generate child private keys. This compares to non-hardened derivation which uses parent public keys in the hash function. Since Bitcoin Core uses hardened derivation while the online tool that you mentioned uses non-hardened derivation (and also different paths), there is a natural mismatch in the keys generated by the two of them.

Bitcoin Core generates private keys using the hierarchical deterministic key generation using the path m/0'/0'/k' where k is the kth key generated from the master private key. Most wallets use the path m/44'/0'/0'/0/k for generating the kth receiving key.

  Bitcoin Core generates its private master key from hdseed? And if so, is that operation reversible?

HD seed is used to generate the master private key using a hash function. So the operation is only one way and cannot work the other way.

  Is the way in which I am generating the hdseed from the mnemonic correct?

It looks to be correct but on other aspect, the mnemonic that you provided in the question is not valid (I'm unsure if it was intentional) as the checksum does not match up with the entropy.


Help! I sent coins to my bitcoin wallet before it was properly synced!

Yes it is, worry not.

The client can generate valid addresses without ever being connected to the internet.

When the blockchain finishes downloading, you should see the incoming transaction.


If a user recovered data directory of LN node software with an old backup, what would happen? Would cooperative channel closing be possible?

No, a mutual close is not possible. For signing a mutual close, both the parties should be aware as to what the current state of the channel is at. Since one of the party has fallen behind, it does not know how much it is owed (or more correctly cannot prove to the other party how much it is owed). Moreover, if the last signed commitment transaction included adding of HTLCs, it is impossible for the fallen behind node to know what those HTLCs are, if the pre-images were sent, or if the HTLCs have timed out.

The one way that can be though of is that when the other party detects that its peer has fallen behind, it sends its peer the last signed serialized commitment transaction (without signatures) that it holds and the signature that the fallen behind peer sent it. They can then negotiate the closing condition including the fees. However, the protocol allows only messages that are not more than 65535 bytes long. Commitment transactions can be as much as 400,000 WU (>100,000 bytes) so it would not fit in a single Lightning message. May be the protocol can use the new TLV format to indicate multiple messages to follow, but as is, the current specs do not allow it.


It was the suggested fee that your app set, I believe you can also customize fee size on most apps, but the suggested fee is for confirming the transaction ASAP. I believe POS stuff like that doesn't really care for confirmation time so you can safely set a lower fee.


Are smalltime block chains susceptible to brute force liars?

Yes, many small coins are susceptible to such attacks. However, the value of the coins is so small that performing a 51% attack on the coin has almost no real use whatsoever. The coins that do actually have value where performing a 51% attack would actually result in non-negligible gains for the attacker are more difficult to attack because they are actually used.


Why is the full Merkle path needed to verify a transaction?

If you have A, HB and HAB you can obviously check whether A fits. As Jestin noted this is essentially a full Merkle tree with two leaves.

However, as a thin client, you only have readily available the Merkle root (which is in the block header) and get told about A. The intermediate levels of the Merkle tree are not provided, therefore, to calculate them, you'd need the block's complete set of transactions.

Image via Mastering Bitcoin

So, for a thin client, we calculate the Merkle branch instead. For the Merkle branch, we just need the transaction's position in the block's transaction list and the hashing partners at each level, instead of the complete set of transactions. A Merkle branch is impractical to fake because it would require finding of a hash collision (which is not doable, or mining wouldn't work). So by going up the tree and combining our result with the respective hashing partner at each level, we finally get the Merkle root. Thus we can prove membership of the transaction in the block.

In the example image, you only need to provide the blue information to link HK to the Merkle root, whereas checking the whole Merkle tree would require all transactions from  A to P and the Merkle root.


many exchanges are only cryptocurrency-to-cryptocurrency-exchanges. that means: you must buy bitcoin at any other place and then you can deposit it on kucoin, exchange it to another cryptocurrency and withdraw it. you can not pay with fiat-currencies (and you can not deposit/withdraw fiatcurrencies) on this exchange.


No your funds would still be at risk. There are only a few popular wallets that use seed phrases.
Most wallets use BIP39(https://en.bitcoin.it/wiki/Seed_phrase) but there are some that use different versions or no seed words at all.
Electrum does not ouse BIP39, see their docs explaining why. https://electrum.readthedocs.io/en/latest/seedphrase.html
It would be extremely easy for an attacker to try the most popular versions and steal your funds.


Why is my lighting node not routing any transaction?

Obviously for questions like this I can't give a 100% certain answer as I would have to look at your nodes logfiles and configuration / state. However I can make some (hopefully) educated guesses and we can see if that helps you.

First of all it seems like you kept the standard base fee and fee rate. Following my analysis and video it seems pretty unlikely that payments are routed over your channels as there are many people currently offering cheaper routing.

Secondly if I read the data from 1ml correctly besides 1 channel with lnbig your channels are all channels that you have created in the past. If you have never paid someone the entire balance of the channel is on your side meaning they can only be used for routing if you also have inbound capacity (which seems to be the case only with the lnbig channel)

Last but not least: it is well known that lightning is still not very wide spread. There are currently only a few services and experimental projects using the technology so that many people don't use it for payments yet. For example my node has optimized routing fees and just earned a couple satoshis from a few hundred routing attempts over the last 6 months. Roughly half of the routing attsmps actually fail because I have way more inbound than outbound liquidity (the opposite situation from you)

There could be other errors which would need a close look at your logfiles / configuration.


What is the recommended OS for compiling a Windows binary for Litecoin?

The Litecoin source tree, in the doc/ folder, provides a file regarding building on Windows, using MinGW and MSYS. I can't personally vouch for those instructions, never having used them myself, so if you go that route, good luck. The way that the release binaries are built, if I'm not mistaken, is using the Gitian builder. If you're looking to do a Windows build, I would try that. If you want to actually use Gitian, you can clone the repo, and use the readme file to get Gitian set up, and then follow the build segment of the release process to do the actual build. On the other hand, if you're not necessarily looking for determinism or the ability to reproduce the exact build, you could try taking a look at the Gitian build scripts to see what packages are being used, what commands are run, et cetera, and try to reproduce that on a Linux system.


Not possible to load the blockchain in multibit so can't pay or recieve either till it's loaded

Have a read of this support note on multibit.org which looks like it covers that error:
https://multibit.org/en/help/v0.5/help_support_blockStoreException.html

BlockStoreException
You see a BlockStoreException very occasionally when MultiBit starts. It prevents you synchronising with the Bitcoin network.
You can fix this problem by doing the following:

Find where MultiBit is storing your user data - see the help topic Troubleshooting

Shut down MultiBit

Go to your MultiBit user data directory - worked out in step 1 - and delete the file multibit.spvchain

Start up MultiBit again

It will then regenerate this file and start syncing. After it has synced you should see all your bitcoin in your wallet..


bitcoin-cli stop
Then edit your bitcoin.conf with nano bitcoin.conf
Then edit or add the entry rpcpassword=yourpassword and rpcusername=yourusername
Save it
Restart bitcoind


How do I move wallet.dat file to a different location?

If you have already downloaded the data then you will have to move the data to the new folder. If you want to store them in D:\BitcoinData then click on "Properties" of Bitcoin.exe shortcut and add -datadir=d:\BitCoinData at the end as an example:

  "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=d:\BitCoinData


Can I get Bitcoins anonymously by having a friend perchase them from an exchange and tranferring them to me?

At best, you're going to get Pseudonymity doing things that way. A determined adversary will know that your friend got the bitcoins and transferred them to someone. It wouldn't take that much digging to find out who your friend transferred those bitcoins to.

For example, if you were to purchase something illegal with those bitcoins and law enforcement cared about it, they would find out that these bitcoins at one point were with your friend. At that point, they'd go and find out from him who he sold the bitcoins to. You would be found out very quickly if they can locate your friend. This is, in fact, the sort of thing detectives do all the time.

You'd have much better luck tumbling your bitcoins.


Bitcoin wallet address format representation

You are trying to transact with two different types of cryptocurrency.

You cannot send/receive Bitcoin from an Ethereum wallet and vice versa.


P2WSH-MultiSig fails with documented OP_0 workaround

The real requirement is that the extra input to OP_CHECKMULTISIG is a zero (that is: the empty byte array).

For non-SegWit inputs, the only canonical way to get such a zero on the stack is by including an OP_0 in the scriptSig. OP_0 just pushes an empty byte array onto the stack.

In SegWit inputs there is no longer a script to build that stack. Instead, you specify the stack directly. As a result, not just the recommended way, but the only way is adding an empty array to the scriptWitness.