How do Bitcoin clients find each other? What protocols or algorithms are Bitcoin clients using in order to find their peers? I learnt that BitTorrent clients may rely on central computers called trackers. Do Bitcoin clients need any kind of central servers or nodes in order to operate?

Bitcoin clients use several methods to locate other clients. The primary method is a list of nodes from a previous connection to the network. The works very well for everything but your first connection or a connection after a very long period of disconnection.

For the case where you have no previous known IPs or they aren't usable, the primary fallback method is by DNS seeds. Several host names (such as dnsseed.bluematt.me) are maintained that resolve to a list of IP addresses known to be running nodes. Should that fail, the client has a list of IP addresses believed to point to stable nodes hard-coded into it.

One method that used to be used, but that has since been abandoned, was having the clients locate each other using an IRC server. That worked similar to a BitTorrent tracker.

Once you are connected to the network, you will begin to receive lists of IP addresses and ports of known clients.


What prevents an attacker from doing DDOS on bitcoin network by sending billions of transaction to himself? I know that transacion fees on low-priority transactions adds additional cost, but what if an attacker uses a lot of 0.100001 BTC transactions, so he doesn't have to pay the fee, because transactions are greater than 0.01 btc, and wouldn't be considered low-priority. There wouldn't be any loosing of money, because there are no transacion fees to be paid. Only huge investment. What would be the amount of bitcoins needed for that?

This attack wouldn't work very well, no matter how much money the attacker had.

Your question seems to be based on the assumption that transactions larger than BTC 0.01 can always be sent without fees.  This is not accurate.

There are two main risks from such an attack:

The attacker's transactions might occupy all the available space in blocks, preventing other people from having their transactions confirmed.
The nodes on the peer-to-peer network might use a lot of bandwidth relaying the attacker's transactions, and not relay other transactions.

What I will describe here is how this issue is avoided by miners and nodes using the unmodified Bitcoin Core software.  The rules implemented by this software are explained in detail here, and what follows is merely a summary. Of course, people are free to use other software, so these rules are not universally followed.  Nevertheless, as long as a significant fraction of miners / users do something similar to this, the attack won't cause serious problems.

As for 1, when selecting which transactions to include in a block, transactions with fees are generally preferred to transactions without fees, and higher fees are preferred to lower fees.  So your attacker's zero-fee transactions would generally not displace those of users who did pay fees.

As an exception, 50 Kbytes in each block are reserved for high-priority transactions, even if they have no fees.  Priority is set not only by the size of the transaction, but by the age of its inputs (the so-called "bitcoin days destroyed" metric).  If our attacker wants to make lots of transactions, he will have to send the same coins over and over again, meaning the age of the inputs will be low.  Other transactions that go unconfirmed for a while will slowly gain priority and eventually exceed those of our attacker.

So in summary:

Fee-paying transactions would not be disrupted
Non fee-paying transactions might be delayed, but would still eventually go through.

As for relaying, a simpler rule is used: there is a flat limit on the number of bytes per minute of non-fee-paying transactions that will be relayed.  Fee-paying transactions are not subject to this limit.  So:

Fee-paying transactions would still be relayed as before
Nodes would not use an excessive amount of bandwidth in relaying the attacker's transactions; most of them would not be relayed
Non fee-paying transactions might have a harder time being relayed.  Users could avoid this by including transaction fees, or by submitting their transactions directly to miners without using the peer-to-peer network.


Why are the results of the Coinish Bitcoin calculate so grim? I am currently investing into a new gaming PC with a Radeon HD 7990. According to objective reviews (e.g. ExtremeTech Review) this card outperforms many the competitors on the market, especially when it comes to bitcoin mining.

When I played around with the expert settings of the Coinish Bitcoin calculater, I quickly realized, that even with my cheapest energy provider (~0.1$/KWh) I will not be able to break even, considering the price of the card.

In addition I tried the same calculation with the values of high-end asic devices that I found available online, similar results.

Is this calculator too pessimistic or is it really not possible to expect a solid ROI with high-end hardware (GPU or asic) at the moment (End of 2013).

I started around March with 2 GPU's. My electricity is free and bitcoin price has tripled since then. I still haven't come close breakeven.

Back then I knew it would take a long time, and I knew the ASICs were coming. I did it purely out of interest and fun.

There really is no other reason to start GPU mining now. Even with everything free, it's just wear and tear on the hardware.

So the answer is: that calculator is probably right. Math doesn't lie, I guess.


Is there a maximum balance that a single address can hold? Is there a maximum number of satoshis that a single address can control at a single time? I ask because when I generate regtest blocks to a single address, it's balance gets stuck at 1494999998350 satoshis (14949.99998350 BTC), and doesn't increase anymore from that point. All balance for that address is from coinbases, not vouts.

Nope. Not 1 bit. A balance (in this context) is the sum of all UTXO's for a given address. There is no limit on the number of UTXO's or their total amount (from the perspective of how the blockchain works and the blockchains limitations).

Software interpreting the balance may have limitations on consuming, processing and/or displaying a number beyond a point. Int32 vs Int64 for example: https://stackoverflow.com/questions/9696660/what-is-the-difference-between-int-int16-int32-and-int64

Here's an address with a balance of 138,660 BTC at the time of this post:
https://longhorn.bullpay.com/?gateway=2&data=3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r

Note: This answer is specific to the question and specific to Bitcoin. For the sake of brevity situations where "creating" tokens or currency on another chain in amounts that could theoretically "break" anything is not covered.


Confidential transactions: how can they be verified by the network? I'm currently trying to understand how confidential transactions would work. I think I was able follow all the explanations about Pedersen commitments and the range checks, but I'm still missing one piece of the puzzle: If the network doesn't know transaction amounts, how can it verify a transaction? It doesn't know whether the account balance is sufficient. How can the network even know account balances when the amount of incoming transactions is hidden?

It would be great if anyone could shed some light on this.

If the network doesn't know transaction amounts, how can it verify a transaction?

That's exactly what Pedersen commitments allow you to do.

Each of the outputs contains a commitment P(v,r) = vH + rG, where v is the value and r is the blinding factr. The network does not know v or r, but does know P(v,r) (and H and G, which are constant).

Pedersen commitments have the property that they're linear in both arguments. This means that P(v1,r1) + P(v2,r2) = P(v1+v2,r1+r2).

For every transaction, a network rule requires that the sum of the output's commitments equals the sum of the commitments of the outputs spent by the inputs. This means that the sum of the output's values must equal the sum of the input's values, and that the sum of the blinding factors must equal the sum of the input's blinding factors.

The range proofs are there to prevent overflow in the value addition.

  It doesn't know whether the account balance is sufficient.

There is no 'account' balance in Bitcoin. Transactions create outputs by burning outputs created by other transactions. Your wallet shows the sum of the values of all outputs you can spend. The only requirement is that a transaction does not create more in outputs than it burns in its inputs.

  How can the network even know account balances when the amount of incoming transactions is hidden?

It can't. The purpose of Confidential Transaction is to prevent the network from knowing anything about anyone's balances. The only necessity is that individual wallets are able to determine how much they're able to spend. In CT that is solved by sending that information in encrypted form along with the transaction, with the receiver's public key.


Where can I find how much one XRP (Ripple unit) is worth? XRP are the units of the new Ripple.com system.

Where can I find how much they're worth right now? Historic charts?

Update 2: There are now more traditional price / volume charts:

BTC:Bitstamp/XRP at RippleCharts.com
USD:Bitstamp/XRP at RippleCharts.com

Update: Ripple Live Orderbook and Charts by webr3 provides various bitstamp style charts and orderbooks for various XRP/xxx pairs.

Update: The Ripple Ledger Explorer by melvster shows a graph of Ripple vs Bitcoin prices.  It also shows recent ledger activity.

Early on there was also a manually-updated list at:

Ripple: XRP Price Tracker

The discussion there had a nice example of what an order book snapshot from the ripple client looks like, with headers.

The #ripple-market irc channel at freenode.net also shows real-time trades via a "Streaming exchange feed for notable #ripple gateways" all trades.  You can see it via

freenode Web IRC

A trade example looks like this:

< ripplebot> TRD bitstamp 730.698114 @ 48,713.2076 BTC rwdLV79WzXmFuzP2cBwTG6mtXcfSnCjtoF #142

I assume that means that the price for that transaction was 48,713 XRD per BTC, and I'm guessing that 730 XRD were traded at that price via bitstamp, but I haven't seen good documentation yet.

Here is an example ASK report:

ASK bitstamp 347.152555 @ 41,854.251463 BTC rwdLV79WzXmFuzP2cBwTG6mtXcfSnCjtoF #143

The code for ripplebot can be found at

rippleFoundation/ripple-watch · GitHub


Which is the more productive miner output k/sh or G/hs Which would be the most efficient and profitable miner, one at k/hs or g/hs ?

I am seeking to find which "miner" algorithm i.e.  daggerhashimoto blake2s etc would be best to mine with most of the time rather than enabling all

Your question doesn't really make much sense, I'll explain why:

As a miner, the number of hashes per second you can perform is relevant to the amount of payout you'll receive. More hashes per second for the same mining algorithm means a higher payout, all else equal. The 'k' or 'G' prefix is the shorthand for an exponentiation:

1 kh/s = 10^3 h/s = 1,000 hashes per second

1 Mh/s = 10^6 h/s = 1,000,000 hashes per second

1 Gh/s = 10^9 h/s = 1,000,000,000 hashes per second

etc.

With that in mind, the reason I say your question doesn't make sense is that the number of hashes per second is only one part of the equation for determining your mining income. The algorithm that allows your hardware to do more hashes/second is not necessarily the algorithm that will be most profitable to mine. There are many other factors, such as what your share of the network hashrate is, what the price of the coin you are rewarded with is, etc.

As a toy example, consider 'mining algorithm A' (maA), and 'mining algorithm B' (maB). With maA you can only do 1 h/s, but with maB you can do 1 Gh/s, so obviously you can perform way more hashes with maB.

However, if the total network hashrate of maA is only 5 h/s, and the total network hashrate of maB is 100 Gh/s, then you will have a much larger share of the hashrate for maA (1/5) than for maB (1/100). Assuming the block reward is equal, it will be more profitable to mine on maA, despite that apparently low hashrate.


distinguish change address from real origindestination a lot of bitcoin clients now send change address balances back to the origin address, by default, to make it easier for people to keep track of their balances.

with this in mind, those transactions are easy to reveal which address is the origin, the destination and the change address.

Also this singles out transactions that do not behave this way, where the origin address splits the transaction into a real destination and a new change address and coins sit in both. Just from looking at the blockchain, how would one decide which address was the real destination and which one was the new change address. Would it be the timestamp each address was created or similarly when it was first revealed to have a transaction?

There is no way to know for sure which address is which.  This is part of the reason why some clients use a new address for change, for privacy; an observer will not be sure which coins now belong to whom.

There is no public timestamp recording when an address was created.  If one of the addresses has been used before and the other has not, this might suggest that the new one is for the change; but it could also be that both outputs are going to two different people, or that the sender is sending coins to herself and both addresses are "change".


How to restore my Bitcoin Core wallet from seed phrase I have my Bitcoin Core wallet protected with passphrase for a long time ago. Now I'm trying to move out the coin from there but unfortunately I forgot the passphrase. When finding for recovery info I only found the list of seed phrases assigned to this wallet.

Is there anyway I can recover my wallet with seed phrase only? Thank you very much in advance for any advice.

Bitcoin Core is not affiliated with the website you downloaded the node installer from - bitsblock.io, and the official Bitcoin Core client does not provide functionality you ask about. I noticed that when you click on download button on this website it takes you to some restore form. This seems very sketchy - I'd never provide online my private key nor any other means to derive it (such as list of backup codes, phrases, passwords, etc.). Try looking for legit wallet that supports BIP39, I cannot vouch for that but supposedly Electrum wallet does that. Also, as mentioned here, it might be actually a restore phrase for blockchain.info online wallet (though as mentioned earlier, I would discourage entering recovery phrases on any website).


Would it be a good idea to have several different *coin to protect oneself from fluctuations? I'm interested in *coin, but I'm afraid of sinking money into something out of idle curiosity and then losing that money to value fluctuations. Would it be a good idea to have several different *coin (lite, doge, idk what else there is) so that the fluctuations balance each other?

Have different *coin in the past gained and lost value in 'lockstep', or totally independent or inversely?

I'm aware that I would also loose the chance to gain money from course fluctuations, but I don't that's something to loose sleep over.

I don't see how different coins would protect against volatility, as Bitcoin is by far the leading cryptocurrency, and the others (even all of them combined) are really totally insignificant in terms of market cap and trading volume.

If you want to protect against volatility (given that you measure volatility in terms of value expressed in fiat currency), there's two options:

use Coinapult Locks
keep part of your money in fiat

Simple as that. Seriously, just not investing part of your money in something is the best and easiest way to suppress its volatility.


How Does Bitcoin Core Client Keep Track of Longest Chain/Strongest PoW Chains? Bitcoin Core stores blocks in files in local disk. And it uses LevelDb to form an index on top of block storage to make it faster to retrieve a block (basically a simple key-value pair db). See this for more details.

Also Bitcoin Core stores all the blocks that are not that are not in the main chain in case a fork happens and one of them becomes part of the main chain.

How does Bitcoin Core scan the local storage to find the chaintip of the main chain which have most number of blocks? Does is keep a list of heads in memory? It would be extremely nice if you guys can redirect me to the location in the Bitcoin Core source code that handles that process.

You're looking for validation.h and its corresponding .cpp source file.

You should start at CChainState::ActivateBestChain. This subroutine calls CChainState::ActivateBestChainStep which runs the logic you're interested in - stepping one by one of the blocks, cleaning up and reorg'ing from lowest to highest PoW.

First, ActivateBestChainStep walks the chain in a while loop: while (m_chain.Tip() && m_chain.Tip() != pindexFork) cleaning up blocks which are not in the best chain using DisconnectTip(state, chainparams, &disconnectpool). This partly answers your question - all the blocks which aren't in the best chain are weeded out here.

It then walks through the current CBlockIndex organizing blocks using the next while loop: while (fContinue && nHeight != pindexMostWork->nHeight). pindexMostWork is a CBlockIndex that contains the blocks with most work. Inside there is a loop which selects the blocks it should connect to the best chain: while (pindexIter && pindexIter->nHeight != nHeight). It pushes the candidate blocks onto a locally allocated vector std::vector<CBlockIndex*> vpindexToConnect;.

Next it iterates this new vector in reverse, pushing the blocks with lowest work first: for (CBlockIndex *pindexConnect : reverse_iterate(vpindexToConnect)) connecting each to the tip. The last connected block will be the block with the highest work index. This builds a chain sorted from lowest to highest work.

Several places in the code call ActivateBestChain, among them:

invalidateblock and reconsiderblock in rpc/blockchain.cpp
ThreadImport in init.cpp
ProcessGetBlockData and Processmessage in net_processing.cpp
Several subroutines in validation.cpp itself

You can use any of the above to trace how and when a new best chain is activated. I think the most interesting ones are in net_processing.cpp as those are the ones triggered by messages received from the network.


How does the 'queryroutes' function in lightning's LND calculate the route fees? I am testing my own routing implementation and for some weird reason a handful of channels reject my payment stating InsufficientFee.

The scenario is A -c1-> B -c2-> C whereby Node A is sending a payment to C via B where the channels used are denoted as c1 and c2.

For c1 the node fee policies are

    "node1_policy": {
        "time_lock_delta": 40,
        "min_htlc": "1",
        "fee_base_msat": "1000",
        "fee_rate_milli_msat": "1",
        "max_htlc_msat": "16777215000",
    },
    "node2_policy": {
        "time_lock_delta": 144,
        "min_htlc": "1000",
        "fee_base_msat": "1000",
        "fee_rate_milli_msat": "100",
        "max_htlc_msat": "16777215000",
    },

For c2 the node fee policies are

    "node1_policy": null,
    "node2_policy": {
        "time_lock_delta": 144,
        "min_htlc": "1000",
        "fee_base_msat": "10000",
        "fee_rate_milli_msat": "100",
        "max_htlc_msat": "10000000000",

    }

For an amount of 4999000 mSat queryroutes uses this route and calculates the fees as

{'amt_to_forward': '4999',
                       'amt_to_forward_msat': '4999000',
                       'chan_capacity': '16777215',
                       'chan_id': 'c1',
                       'fee': '10',
                       'fee_msat': '10499',},
                      {'amt_to_forward': '4999',
                       'amt_to_forward_msat': '4999000',
                       'chan_capacity': '10000000',
                       'chan_id': 'c2',
                       'fee': '0',
                       'fee_msat': '0',}
             'total_amt': '5009',
             'total_amt_msat': '5009499',
             'total_fees': '10',
             'total_fees_msat': '10499',}

Could someone please explain in step-by-step detail how the lnd client gets to this value?

To answer your question two things have to be known:

Routing fees are always charged from the recipient to the sender as the fee rate of later packages impacts earlier routing decisions.
Nodes get paid a routing fee to forward a package on an outgoing channel.

The first remark is not of importance for your case as the path only includes 1 routing node. The second remark means that only the fee police for channel c2 are relevant. Node A does not charge itself a routing fee on channel c1 to forward to B and node B would only charge a fee on channel c1 if a paymant was to be forwarded to node A

So let us look at the payment amount and the policy of channel c2
the policy says:

 "fee_base_msat": "10000",
 "fee_rate_milli_msat": "100",

where the payment_amount is 4999 that means that you have to send an onion to B that has the following amount of msat

payment_amount * 1000 + fee_base_msat + payment_amount * fee_rate_milli_msat / 1'000

pluging in your numbers this means:

4999000 + 10000 + 4999 * 100 / 1000 = 5009000 + int(499.9) = 5009000 + 499 = 5009499

That is exactly the amount your node sends on its way to complete the onion. Also note that if your node would have been forwarding that payment from anouther node E the other node would have to use that result as the payment_amount with the above formula and your channel police from c1 to forward the payment. That is what I meant in the first remark that the amounts are calculated from the receiver to the sender.


bitcoin: time of block size I'm trying to figure out the size of the block

and i have trouble calculating the number of bytes of time

one block has time like this:
"time":1516430234

After counting the bytes, the value is :5

This is a mistake, since it should be only 4

Does anyone know the solution?


Getwork and GetMemoryPool - why is previous block hash different? When I called:

print bitcoin.getmemorypool()
print bitcoin.getwork()

using Python JSON for a testnet BitcoinQT server, I got the following responces:

{'previousblockhash': '00000000032e361b246e96c4e594523b6ff42bc0527e560f203fb20a08a86185', 'transactions': ..., 'version': 1, 'coinbasevalue': 5000400000, 'time': 1329342730, 'bits': '1c2336a4'}
{... 'data': '0000000108a86185203fb20a527e560f6ff42bc0e594523b246e96c4032e361b000000004c50804820b143e1583c8c49dd43a6ddb8bc777c57c2da4a92b39ee0e709bf504f3c290b1c2336a400000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000', ...}

Comparing the previous block hash from GetMemoryPool and one extracted from the block header from Getwork:

00000000 032e361b 246e96c4 e594523b 6ff42bc0 527e560f 203fb20a 08a86185
08a86185 203fb20a 527e560f 6ff42bc0 e594523b 246e96c4 032e361b 00000000

From what I can see, the data is reversed in chunks of 4 bytes. Why is such a procedure done, and what other fields from those two RPC calls undergo such an operation?

The value of previousblockhash in getmemorypool output is the block hash in big-endian order.

The value of data in getwork output is formatted as I described in this answer to your question about how hash1 is calculated.

This byte order reversal on 4 byte words is done by a function called FormatHashBuffers in main.cpp.  It's only done for the data and hash1 fields of the getwork output.  There's no comment explaining why it's done.


How do I transfer my wallet? If I have my wallet on my computer, and I would like to transfer it to a Laptop or make a backup, how do I do that? And also, is it possible to transfer an online wallet to an offline wallet? Like from CoinBase to my Laptop?

If you're using a client, you can just export the wallet.dat through an option, be sure to encrypt it!

If you need to move your Coinbase "wallet", you can just send the balance to an offline wallet address.


how does bitcoinjs-lib grab utxo So, Let's say I want to create a transaction by using bitcoinjs-lib.
As far as I can see, this library doesn't provide the help so that it can automatically figure out/grab unpent transactions for inputs and create a transaction magically.
My question is: Am I the one who has to know unspent transactions that I want to use for the inputs in advance ?
If the answer is no, then can you point me to the bitcoinjs-lib file that does this ?
If the answer is yes, how do I get unspent transactions ? By looking at my transaction list on blockchain and getting each one of them's txid and vouts seem not reasonable. Any idea ?

Yes you need to provide the UTXO details when building a transaction in bitcoinjs. One should not have to trust a library to provide blockchain data, the library works like a calculator and processes the data that it is given. It's not unreasonable at all, these details are easy to get from your node or an explorer.


How to restore wallet from wallet words after hard drive crash with no back up? If I lost wallets on hard drive crash, how do I restore with just my wallet words? Restoring data from back up is not working

Since you added the Electrum tag to the question, I'll assume you're using Electrum.

When you first start up Electrum, you get the choice of creating a new seed or creating a wallet from an existing one. At that point you would select to enter your existing seed words, and it should recover your wallet.


How can I search for OP_RETURN data? Is there any way to check for this data in blockchain?

I want to search this value: 554e6963444320 and want to return this transaction https://blockchain.info/tx/7e92e90f221ad28daf42b5b8bda4c8e244e37af48527fcd12b2518db5d3315bd

The Chain.com API offers functionality for returning OP_RETURN data by:

Address
TxID
Block height

The JSON return data from the REST API has a text field which is meant to be the decoded hex data sent (ie 6a``hex data) but it's returned in the format \\x``hex data.

In Python you can simply do this:

import __future__
import requests; from binascii import unhexlify
rdata = requests.get("https://api.chain.com/v2/bitcoin/addresses/%s/op-returns?api-key-id=DEMO-4a5e1e4" % "1Bj5UVzWQ84iBCUiy5eQ1NEfWfJ4a3yKG1") # substitute URL here
assert rdata.status_code == 200
jdata = rdata.json()
hexdata = [unhexlify(str(t["text"]).encode("utf-8"))) for t in jdata
print(hexdata)


When was the paper of bitcoin announced? When examining about this, it is said that many are November 1, 2008, but on the other hand, there are sites that are on October 31st. Which one is correct?

According to the mailing list archives, the mailing list received Satoshi's email at Fri Oct 31 14:10:00 EDT 2008. However the mailing list is moderated so perhaps the email was not received by everyone until a day later on November 1st. The first response to the email was sent on November 2nd, so it may be that the email was not forwarded to the list for a day or so.


Why does Bitcoin Core not produce a Reject message for Conflict TXs? From the perspective of a full node participant in the network, why is it a bad idea to convey to a peer that a transaction has been rejected because its either a conflict transaction/high fee transaction or a transaction which already known to it?

I noticed that in the Bitcoin Core source code that REJECT_CONFLICT is set at 0x102 which is greater than REJECT_INTERNAL.

if (state.GetRejectCode() < REJECT_INTERNAL) // Never send AcceptToMemoryPool's internal codes over P2P
    pfrom->PushMessage(NetMsgType::REJECT, strCommand, (unsigned char)state.GetRejectCode(),
                       state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), inv.hash);

Bitcoin Core code excerpt from src/main.cpp.

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.


Is there network split risk for Taproot activation with two releases (Bitcoin Core and Bitcoin Taproot)? In this article from Aaron van Wirdum he states there is a risk of a network split with two releases (Bitcoin Core and Bitcoin Taproot) not following exactly the same activation mechanism(s)? Is this true?
This question was asked by Andrew Asmakov and has been paraphrased.

No. With a softfork, a network split is only possible if miners create invalid blocks. This is something they can do with or without a softfork, so it is not an issue specific to softforks.
It is important for the economy to use their own full nodes to avoid the risk of being led off by a miner attack in the form of invalid blocks. This remains true with softforks, where upgrading is necessary to retain full node security.


What are the reasons behind pool transactions fees and what are the consequences? Few days ago I have read this.

For people who are too busy I will try to explain what is written there (this is my understanding which might be wrong, so if you think that it is incorrect, please edit it):

Because of a lot of micro-payments from satochidice, the blockchain has reached a reasonable size and pools are thinking about implementing transaction fees.

Is it possible that at some time major mining pools would decide that they are not going to validate transactions if fee is less than something and thus would be dictating their rules?

Transaction fees have been a part of the Bitcoin protocol from the beginning. They are a core part of the protocol and are designed to be the long term incentive for miners.

And, Yes, miners will often exclude transactions without fees (or give them a lower priority). It's been that way for a long time although it does seem to be getting more common in my opinion.

Satoshi dice has indeed had an effect on the network, but transaction fees have been a part of the protocol from the beginning. The consequences of fees are many, too many to discuss here, but include the motivation for mining (especially as block rewards decrease) and protecting the network from spam and attacks.


bitcoin reorg question if a block takes 10 minutes to be mined

does it need 21 minutes to be reorged?

if the reorg started immediately after the block was mined

because 100% was mining and 51.5% will reorg

how long does it take to reorg 5000 block ? 70 days?

is 70 days of reorging a huge thing that would make the people stop believing in BTC ?

all of my questions and availability here is because i am selling my business for 5300 BTC and i dont need to be F&&&ed with reorging later if i will not use them

this was also my point in the last questions for creating custom wallet offline

First you need to define "reorg". Under the definition I'll use, the minimum reorg is two blocks. The definition would be:
"A reorginization occurs when a block is broadcast with a history that is incompatible with the previously work-heaviest** known blockchain, under the same consensus rules"

Say a block is mined onto the height 593000 block, with hash 000000000000000000a11... so that apparently, block 593001 has been found, and many miners are now mining based off of this hash.

Now imagine that someone broadcasts block 593002 with hash 000000000000000000c84...but upon examining block 593001, you see that the hash is 000000000000000000b5c...

A reorg has just taken place. Someone mined block 593001, and without broadcasting it (or perhaps after broadcasting it too late), mined 593002 on top of it. Now any transactions in the block with hash 000000000000000000a11... have not been confirmed (one of which was the original miner sending the block reward transaction to themselves), since the (valid) block that contains them has been orphaned.

As far as "how long", a reorg is relative to the observer, so one could technically take place before you observe the original chain at all.

** essentially, the longest chain, but there are exceptions where a "reorg" could be a shorter chain in terms of number of blocks, when a shorter chain contains "more" proof of work. This is outside the scope of this answer.


Bitcoin Transaction Protocol Question (maybe specific to Coursera Bitcoin Lecture) In the Coursera course "Bitcoin and Cryptocurrency Technologies" course, a coin called ScroogeCoin was introduced.

This coin is similar to bitcoin in that each transaction consists of a set of inputs and outputs. Inputs point to outputs from previous transactions with corresponding signatures, and outputs contain the value and address the value is applied to.

The protocol checks that (sum of input values) - (sum of output values) >= 0, and this difference is the transaction fee.

I feel that this condition is too loose and there may be a potential problem. For example, suppose Alice has a coin of value 50 and spends 100, while Bob has a coin of value 100 and spends 50. Both of these are in the same transaction. Then the protocol would allow this to pass.

I feel that the protocol should check instead

For all addresses, (sum of input values from address) - (sum of output values that is spending from address) >= 0

This is because the original protocol allows spending from someone else's address. This sounds like something that can be exploited e.g. an implicit money transfer from Bob to Alice is hidden. We can assume Alice and Bob are colluding to achieve this.

Is this benign?

It doesn't matter whose coins are funding (inputs) for the transaction the validation check still works.

  (sum of input values) - (sum of output values) >= 0

There's nothing that states sum of input values on a per user basis. As long as the total value of the inputs, no matter who or where they come from, exceeds or equals the total value of the outputs the transaction passes the check.

Update: It's not an exploit. Each transaction input is treated separately and the condition to spend each input must be met separately. If Alice supplies an input tx then she'll also have to supply a scriptSig for that single input to prove she's entitled to spend it. Likewise with Bob's transaction, he'll have to supply a completely separate scriptSig that proves he's entitled to spend his input transaction.

Alice can't spend Bob's transaction and vice-versa (unless it's a multisig, spend by anyone etc) no matter how they are combined as inputs.


Use bitcoins at bitstamp to buy something online How can I use bitcoins at bitstamp to buy something from some online seller?

If you want to buy something with bitcoin, you either need to find a seller who accepts bitcoin as payment, or you need to convert your bitcoin into a currency that seller will accept.

Assuming that the seller in question accepts bitcoin, you will need to send that seller bitcoin in whatever way the seller has set up for you to do so.  Usually this means clicking a link, scanning a QR code, or copying a Bitcoin address into your wallet software.  From there, the seller will see your transaction in the mempool, probably wait for at least a single confirmation, and then process your order.

If the seller does not accept bitcoin, you will need to convert your bitcoin into a currency that is accepted.  This can be done at an exchange (such as bitstamp), using whatever process and rules that exchange has in place.  Usually, this means tying your account with them to a traditional bank account, so that the exchange can deposit your fiat currency into that bank account.  From there, simply pay the seller in whatever means your bank provides.


Tracking transactions in both directions I have an example of a transaction. I deleted some fields which don't play any role for my question. Also I reduced large hashes and IDs.

{
 "txid": "8d554",
  "vin": [
    {
      "txid": "d3117",
      "vout": 0
    }
  ],
  "vout": [
    {
      "value": 1.99995000,"address":"mrL8SS",
      "n": 0
    },
    {
      "value": 3.00000000, "address":"mtK8r",
      "n": 1
    }
  ]
}

From this transaction I can find out which transaction was used for paying outputs of this transaction. Because those transaction is in vin field. Its txID is d3117. So if I want i will be able to find this transaction by using bitcoin client RPC API: bitcoin-cli gettransaction d3117.
  But what if i want to find out, which transaction used THIS transaction as input? Could you guys please tell me, if it's possible or not?

That's not possible without looking through all the transactions after this one and finding the one which spent it. Most block explorers keep a database of the transactions so you could look it up on one of them.


Block chain and its uses cases for a non-financial asset market So i have been reading a lot about block chain technology and its use cases in the finance and cryptocurrecncy markets. One thing that guarantees blockchain's success in the cryptocurrency market is the prevalent financial incentive for the miners to validate blocks of transactions to make it part of the public ledger (they are rewarded with bitcoins). This financial incentive is associated with a financial asset block chain and partly explains the ongoing boom in the price of Bitcoin. However, as an  economics and technology enthusiast, i am curious to learn more about the inherent incentive structure that would prevail if the block chain is for a non-financial asset (let's say it stores patient's data- a use case for blockchain in the healthcare market)? How can we incentivize miners to validate and solve pending blocks in cases where a blockchain stores a non-financial asset and therefore giving a financial incentive seems impossible?

I would appreciate any resources(articles, books etc) that you guys can share below in the comments. I look forward to doing more research. Thanks!

It's far from obvious that any such system would be usable or secure. But in many places "blockchain" has become a alternative way of saying "cryptography", "digital signatures", or "distributed system" -- all of which might be useful.

Storing patient data "in a blockchain" is one of the more horrifying concepts that I've encountered. I've never seen a good reason for it and in fact there seems to be a perfect mismatch in the technology:  What Bitcoin invented was a way of building a public system of a sort that was previously trivial to build privately.  There are many issues with medical records, making them less private is not generally considered one of them. :)

To me a lot of the blockchain hype feels like "Bitcoin appears to solve a complex problem.  Peace in the middle east is a complex problem, thus the technology from Bitcoin can solve it!".


What are the issues of running lightning daemon with pruning node? Most lightning implementations I came across don't officially support pruned full node.

Why is pruned mode implementation a challenge?
What risk am I taking when I run lnd with pruned bitcoind?

Pruned nodes don't have the ability to make a full index of all transactions in the chain, which makes implementation of tools like Lightning difficult or impossible. There's no risk particularly, a pruned node has the same security properties as a normal one, it just doesn't have historical transaction data necessarily.


Can I find the address of my Bitcoin in the debug.log file? I cannot download the entire block chain (I’ve tried four times now and failed) so I can’t replace my encrypted old wallet.dat file into  the blockchain and do the rescan to check my coin balance. My question is, can I find my Bitcoin address in the debug.log file. Is there a way to use the information in this file to check my Bitcoin balance?

Any addresses will be in the wallet.dat file and can be viewed or extracted without any need to download (synchronise with) the whole blockchain.
You can check the balance of an address by using several different public blockchain explorers and checking the results are consistent.
See also

dumpwallet output documentation & explanation?
What do the different .dat files contain?


When I call the blockchain.info API, I an error. What can i do to solve this problem? A script that calls the blockchain.info API to find the UTXO related to an address

# get unspent outputs from blockchain API

import json
import requests

# example address
address = '1Dorian4RoXcnBv9hnQ4Y2C1an6NJ4UrjX'

# The API URL is https://blockchain.info/unspent?active=<address>
# It returns a JSON object with a list "unspent_outputs", containing UTXO, like this:
#{      "unspent_outputs":[
#   {
#     "tx_hash":"ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167",
#     "tx_index":51919767,
#     "tx_output_n": 1,
#     "script":"76a9148c7e252f8d64b0b6e313985915110fcfefcf4a2d88ac",
#     "value": 8000000,
#     "value_hex": "7a1200",
#     "confirmations":28691
#   },
# ...
#]}

resp = requests.get('https://blockchain.info/unspent?active=%s' % address)
utxo_set = json.loads(resp.text)["unspent_outputs"]

for utxo in utxo_set:
    print "%s:%d - %ld Satoshis" % (utxo['tx_hash'], utxo['tx_output_n'], utxo['value'])

Running this script, shows the error:

Traceback (most recent call last):
  File "get-utxo.py", line 26, in <module>
    utxo_set = json.loads(resp.text)["unspent_outputs"]
  File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

The API returns No free outputs to spend when there's no unspent output, you need to account for that case. You can do a simple check on the status code (200: OK, 500: Error).


Can a Blockchain be Built Like This? Can a Blockchain be Built Like This?

1) Alice sends Bob one X-coin.

2) The blockchain's protocol takes X and the next (say) 100 transactions and puts them in a block.

3) Distributed peer-to-peer nodes verify all the transactions in this block. They all work off the same consensus protocol block rather than creating individual competing blocks.

4) Once 51% of nodes verify and sign that all the transactions in the protocol block are legitimate (and boot illegitimate ones) the protocol stacks the (now immutable) block on the updated, broadcast and accepted chain and pays all miners a fixed percentage of the completed block's block reward (proportional to transferable mining rights they own).

5) Repeat

As I understand it (and I probably don't), a Proof of Permit (PoP) system like this appears better than traditional Proof of Work (PoW) and Proof of Stake (PoS) systems because:

Costly calculations and energy consumption are eliminated;
Mining centralization (and it's regulatory threat) is reduced;
Distributed consensus occurs because miners work off the same block and can't advance and be paid until they concur and sign that block;
The Nothing at Stake (NoS) problem is minimized because miners simply can't create other blocks or chains;
Chronological verification and instantly immutable blocks prevent double-spending;
Coins are freed and spent instead of hoarded and staked like PoS systems;
Downward price pressure is reduced because miners don't have to sell block rewards for fiat to buy electricity for mining;
Miners are paid every time instead of sporadically over time;
PoP remains distributed, decentralized, secure and trustless;

A 51% attack remains possible if an attacker can acquire 51% of the mining rights, although this could be offset by rising permit prices as they did so, and by the fact that increased investment increases an owner's incentive to maintain their system rather than destroy it. A tenant can acquire matches and burn down their apartment building (even without having to acquire 51% of the units) but rarely does.

The above simple logic is likely wrong, I just don't know how. What technical or conceptual errors exist? Please rip this to shreds so I can try to reconstruct it better.

Thanks.

Surely your idea is appreciable but there is some subtle points one needs to consider, some of them I tried to put in brief. Similar ideas are in existence and the community is working to fix the holes. I will suggest reading about Casper(PoS for ethereum), Algorand(S Micali), Bitcoin-NG, CAP theorem, Byzantine agreement etc.

  2) The blockchain's protocol takes X and the next (say) 100 transactions and puts them in a block.

When you say the "blockchain's protocol" accumulates the transaction and puts into them into a block practically these needs to be done by some single miner(or validator or node). There are several questions one has to consider

Q1. Who will have the right to create the block and how to decide it? Also how to ensure the fairness among the miners that they will get in return proportional to the running cost.

Q2. Also what incentivises them to participate in the consensus protocol

  Distributed peer-to-peer nodes verify all the transactions in this block. They all work on the same consensus protocol block rather than creating individual competing blocks.

Q3: How the block will be distributed to the entire network and what consensus mechanism should they follow? Should it be Byzantine Agreement or PoS or PoW?

  Once 51% of nodes verify and sign that all the transactions in the protocol block are legitimate

Q4: What constitutes the 51% nodes in the protocol, for example in PoW it is 51% computation power. Surely it can't be the number of nodes in the network as a miner can create as many numbers of nodes as it want's gaining the absolute majority(Sybil Attack).

The above question will raise the question of the barrier to entry say monetary entry so we are going back to Proof-of-Stake.

Now considering the benefits that you are claiming.

  Costly calculations and energy consumption are eliminated

It purely depends on the consensus protocol miners follow to agree on the majority rule.

  Mining centralization (and it's regulatory threat) is reduced;

If the barrier to entry to the consensus protocol is quite low and if there is no randomization as it is, in this case, the chances that miners will come together till 51% size to gain more than the fair share by rejecting consensus from anybody outside the pool eventually taking all the reward.

  The Nothing at Stake (NoS) problem is minimized because miners simply can't create other blocks or chains;

  Chronological verification and instantly immutable blocks prevent double-spending;

The above two points implicitly assuming synchronization among the clients and does consider the CAP theorem in consideration.

  Coins are freed and spent instead of hoarded and staked like PoS systems;
  Miners are paid every time instead of sporadically over time;

The above two question is the consequence of immediate agreement among miners, which has issues like synchronization and also nothing at stake attack.

I am not certain I understood the following point quite clearly.

  Downward price pressure is reduced because miners don't have to sell block rewards for fiat to buy electricity for mining;


How does the Coin Selection in Bitcoin Wallet for Android work? What is the algorithm in Bitcoin Wallet for Android to select the inputs to create a new transaction?

It appears that Bitcoin Wallet for Android uses the DefaultCoinSelector from bitcoinj.

The DefaultCoinSelector sorts the available UTXO by diminishing age and value:

value [satoshi] * age [confirmations]

Should two UTXO compare as equal, larger value is preferred.

The CoinSelection then picks from the front until the target is reached.

Still trying to figure out whether I understood this correctly:
If the resulting change is large enough to pay for the fee and remain above dust level, the transaction goes ahead.
Else, change will be increased by 0.01 BTC. If it satisfies neither option, the change will be added to the fee.


how to earn a transaction fee for transactions originating from my client I am working on an online litecoin wallet system. For every transaction originated from our site, we need to charge say x% of the amount as fees and it'll be sent to Admin's address ? How can I do that ?

I guess paytxfee is what we are willing to pay others for a particular transaction, right ?

I didn't found any parameter to set the address to which the transaction fees should go ?

Looking for some help...

By definition, "transaction fee" is the difference between sum of inputs and sum of outputs. It always goes to the miner.

What you need is to add an output payable to your account.


What prevents a transaction being added to the block chain twice? As I understand it, a transaction basically consists of a from address, to address, amount and some component that verifies that the owner of the from_address has requested the transaction. A transaction is broadcast to the network in the hope that it will get included into a freshly mined block.

If the miner can choose which transactions to add to a block. How does the Bitcoin protocol stop a miner from re-adding an existing transaction to the chain? and thus recreating the transaction and doubling the effect of the transaction.

Surely it is not feasible to search the entire transaction history to make sure the transaction hasn't already been included.

EDIT - from a bit of further research, it looks like including a confirmed transaction will render a block invalid and it will be rejected by other Bitcoin nodes. But how can you determine if the block contained an already confirmed transaction in an efficient way?

In Bitcoin, each full node follows all transaction activity on the network by digesting the blockchain. To that end, every full node enforces their ruleset on the data that they receive. As (usually) the full nodes all follow the same ruleset, every node indivdually converges on the same state.
Hereby, the blockchain's transaction data represents a journal of the activity, which if digested according to Bitcoin rules yields a ledger of all balances at the current blockchain tip, the Unspent Transaction Output Set (UTXO Set).

Every full node maintains this complete set of UTXOs. Each UTXO is uniquely identifiablee by the transaction it was created in, and the position in that transaction's output list.

When a transaction is confirmed, the UTXOs in the transaction inputs get spent and removed from the UTXO set, while the transaction's outputs in turn get added to the UTXO set. If someone tries to replay the same transaction again, the referenced inputs are no longer in the UTXO Set as they were previously removed and the transaction is just as easily identified to be invalid as a transaction spending made-up UTXOs.


How to sell BCH into BTC I have an Electrum wallet since Nov 2016 with some BTC.

It seems that I automatically own BCH now (is this right?). What is the simplest way to sell this BCH into BTC?

Should I install a BCH wallet software (Electron?), and initialize it with the same Seed as electrum (isn't this dangerous?)?

Or is there another simpler system to sell my BCH into BTC?

Since you're using a local wallet, read these instructions on obtaining your BCH. For safety, you can transfer all your bitcoins to a new wallet first, then no longer use the old wallet for Bitcoin transactions. Also, installing BCH wallet software on a separate machine is a good idea as otherwise the Electron Cash wallet may sweep the machine for Bitcoin wallets and put your new wallet at risk.

There may be simpler methods, but at this point in time I'd expect they would increase your level of risk substantially.

To sell your BCH for BTC, you'll need to find an exchange you trust that handles both.

If you're interested, there was a fork into "Bitcoin Gold" too, on 24th Oct 2017, though it hasn't gone live just yet.


Is there a graph of Namecoin value over time? Where can I find a chart (or even raw data) of Namecoin prices over time?
NMC Watch doesn't seem to provide a link to historical data, just one day.

In BTC? In USD?

It's possible to see historical Namecoin's price chart on NMC Watch, the link provides price chart from June 2 to current date.


Single pool vs multipool mining? I noted that many clients now-a-days have the option for multipool. Regarding such feature I've got two questions:

What are the advantages of being in a multipool setup against the single pool?

Is such setup option fair for those people who are in only one pool?

Multipool clients generally have two sets of functionality fail-over or load balancing.  Fail-over is simply having backup servers in place so that your miner can continue working if your primary server goes down or experiences a connectivity issue.  Load balancing will split up the work across multiple pools simultaneously.  This would make the most sense to me in an environment where multiple people purchase a rather expensive mining rig and want to distribute shares of the rigs capability to accounts that are controlled by different owners.  I can't see a scenario where this functionality could be unfair to someone mining in a single pool.


GreenAddress: Noticfication of receiving transaction I'm developing python project using greenaddress API. I use pycoin package.
I almost completed, but I can't resolve notification problem.
Using greenaddress API, the notification received is as follow.

{'wallet_id': '139183', 'txhash':    '0fd5cdf75d8a9979b454b36ba8dc36917dfc5b3726622f5291a24f0dcd4ab27f',    'subaccounts': [37], 'value': '-207'}

I want to get raw tx from this information, but I can't.
Can I get raw tx from this information by using pycoin and greenaddress API?
Pls, help me.

using pycoin and greenadderss you can't getrawtransaction.

using bitcoin-core you can getrawtrasnaction as hex or encoded.

bitcoin-cli getrawtransaction "mytxid" true


Why is the hashrate getting so high? The Bitcoin hash rate is MASSIVE right now.

What exactly causes the hashrate to increase?

Miners are competing to find valid blocks because each block allows the successful miner to collect a mining reward. The mining reward consists of an amount of newly generated coins as defined by the reward schedule (currently 25 BTC per block) as well as any transaction fees attached to transactions they confirmed with the block.

At ~$400 per BTC, this values a block reward at approximately $10,000. Blocks are found at about 10 minute intervals, valuing the block rewards each day at about $1.4 million.
 As the hashpower of your equipment in relation to the network's total hashpower determines the likelihood of you succeeding at finding the next block, miners invest in better equipment, which in turn creates a market for manufacturers to produce such.

Over the past years, mining hardware has progressed from CPU, to GPU, to application specific chips (ASIC) that can exclusively perform the computations required in Bitcoin mining. Back in 2015 this specialized mining equipment pretty much caught up to the technological state of the art, as the first 14nm chips were produced.

Altogether, the race of ASIC manufacturers to provide the fastest mining equipment and the miners to deploy the same has built up the networks hashrate to an impressive 1.4 exahashes per second, which is about a 50,000x increase since the about 21.6 terahashes per second when the first ASICs were delivered in January 2013.


What does "operation not valid with the current stack size" mean? I'm asking this question to help others who run into the same problem I ran into.  The error is, at least sometimes, misleading and might not be accurate.

The context in which this error is relevant is signing a raw transaction that you created with bitcoin software.  This is a common practice for those who are paranoid, like me.  Here's the basic procedure:

Identify the TxOuts (txid and vout pairs) that you want to spend.
Use https://chainquery.com/bitcoin-api/createrawtransaction or something similar to create a hex string.
Use https://chainquery.com/bitcoin-api/signrawtransaction along with the private keys required to spend those unspent TxOuts.

In that third step, you might get this "operation not valid with the current stack size" error.

The signrawtransaction RPC will verify the input scripts of the transaction after it signs it. If the transaction has not been fully signed (i.e. it isn't complete), then the script verification will fail and produce this error.

This also happens with multisig transactions. When you don't have enough signatures, the script will fail to verify with the error that you see.

See also: https://github.com/bitcoin/bitcoin/issues/9988


Why does the Bitcoin pool reject my Antminer D3 shares? I hope somebody can help, since I have received my antminer D3 and connected it to the antpool, all my shares are getting rejected.
I am mining bitcoins but all of them are getting rejected.
I have uploaded a screenshot below.

Somebody knows what is the solution to fix this problem.

You cannot mine Bitcoin with D3.
You can only mine Dash with a D3.


Is there a correct way to refer to "orphan" blocks? I was reading a passage on the bitcoin wiki that pointed out that it doesn't make sense to call invalid chains "orphans," since, by definition, every block in the blockchain except the genesis block has a parent.

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.
These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.

Is there a better way to refer to these blocks?

Pieter Wuille suggests extinct blocks:

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


Authentication and key distribution in bitcoin After going through the bitcoin protocol documentation it is still unclear to me how the bitcoin client is authenticated. Where can I find an overview of what the client sends and receives on the wire during authentication?

There is no "authentication" in bitcoin protocol. It is not encrypted also.

You can use wireshark to investigate handshake packets


Created genesis block and set up node. How to mine? Everything seems to be going well creating my altcoin for fun. I forked the BlackCoin source on Ubuntu, successfully mined a genesis block, recompiled. I bought a droplet over on digitalocean running Ubuntu 12.04, compiled my *coind from source, and ran it.

I know that worked because my *coin-qt on my local computer had 0 connections before, now it has 1, and my *coind getconnectioncount on my droplet reports 1 connection.

Here is my problem, my client *coin-qt says there are 80000 blocks remaining. Of course, it is stuck on block 0.

How can I fix this and start mining?

If it's predetermined that 80,000 blocks remain, it sounds like you haven't cleared out the checkpoints.

It's been awhile since I looked at anything other than Ripple or Nxt, but you should be able to find the checkpoints by simply searching for "checkpoint" in the code or the assert()s.

Also, to keep yourself from interfering with the original BlackCoin, you might want to use another port.


Block explorer with testnet raw hex data Blockchain.info allows you to look at the raw hex of a transaction. But it doesn't have testnet functionality. Blockexplorer allows you to look at testnet, but I can't find a way to show the hex dump.

Any solutions?

Maybe too late, but here's an example of using Blockr.io on testnet with raw hex dump:

http://tbtc.blockr.io/api/v1/tx/raw/5bb4f41ad7ac687db5126cb66a4971100f4137a3056d85ee27343ce429dbe4bb


What is a stale blockchain tip? Is it a blockchain tip missing the latest mined block? Stale blocks and orphaned blocks are defined here.
What is a stale blockchain tip? Is it a blockchain tip missing the latest mined block? Or is it a blockchain with a stale block (as defined in that post) at its tip?
This question was asked during this Bitcoin Core PR review club session on Bitcoin Core PR 19858

(I don't think of this as a standard term, so the context was useful for me to figure out what this question was asking -- then I realized you're asking about a specific usage I have used regarding some p2p logic!)
I've used the term "stale tip" in the context of Bitcoin Core's p2p logic to specifically refer to the case of our tip not having advanced for a long time. This can arise benignly if the network is slow to find a block, of course; but it can also arise if our peers are not giving us blocks that are being found for some reason.
The "stale tip" detection logic in Bitcoin Core (see here, here, and here) is a simple check to see if our tip hasn't updated for a given amount of time (30 minutes), and if that condition triggers, our p2p logic will try to find new outbound peers to connect to with the goal of checking to see if any peer we can find has a more-work chain than the one we're on (and if we succeed, we will evict an existing peer).
A writeup of this behavior (and some other p2p design considerations) is available on the Bitcoin Core wiki.


Does a Stellar ledger contain all the state of the world? How does it scale? So, I'm new to Stellar and trying to make sense of the (somewhat) confusing terminology here. It sounds like a Ledger is like a block in Bitcoin, in the sense that it opens and closes every so often.

A block in Bitcoin only holds the list of bitcoin transactions that were made in the last iteration, which is why you need to track all the blocks to know the complete state of the world (in Bitcoin). However -

According to the docs,

  A ledger represents the state of the Stellar universe at a given point in time. It contains the list of all the accounts and balances, all the orders in the distributed exchange, and any other data that persists.

so, if that's true, is this scalable? how?

It's my understanding that if a transaction set is voted as valid during an SCP round, that transaction is applied to the "last closedledger".  The new state of the ledger now becomes the "last closedledger" and the process repeats.  So you can think of voting as modifying a big, shared global state.

E.g. if the last current ledger shows Foo: 1 and the transaction is +1 to Foo, when the nodes ratify this transaction one is added to Foo and the ledger state moves to Foo: 2.

The ledgers are "linked" via a cryptographic hash so that they form a chain and you could verify the hashes match...but my understanding is that there's no real need to keep historical ledgers around other than for historical book-keeping/archival purposes.

Consensus is reached through the SCP voting algorithm rather than verifying cumulative hashes (proof of work).  So the current state is valid because it's been voted on being valid, and there's no need to do the whole "validate the universe" sync that happens with proof-of-work blockchains.  I'm assuming that when new nodes join, they just bootstrap themselves from nodes in their trusted quorum slice and there's not really any "verification" going on

It scales because, while you need an entry for all existing accounts, you really only need the current ledger rather than all previous permutations too.

Obligatory disclaimer: new to SCP myself, not a developer on the project but have been reading the whitepaper, may be wrong :)


Can bitcoin be forked in such way that the monetary base increase? Can it be forked into a new coin, such that if i had X bitcoins i will still have X coins in the new crypto-coin, but the monetary base will be 50M coins for example?

Yes. It's possible to do that in a not backward compatible fork (hardfork).

Assumed that the new currency would be bitcoin50 (B50):

You could copy the whole Bitcoin-blockchain (as in every hardfork) but only modify (increase) the future block rewards so that there are around 50,000,000 B50`s available when the reward is 0 in ~100 years.


How do I chose the address to send to in Electrum? Can i send from a new made address with no transactions? How do I chose the address to send to in Electrum?
(for Electrum) Can the seed recovery mechanism in Electrum be bruteforced?

2.1. Since any seed makes some especial addresses (correct me if i'm wrong), (if someone see those) isn't that a way to eliminate the possible words in a seed?
Can I send from a new made address with no transactions? If yes, will that makes my transaction anonymous? (Are the coins connected to the received addresses?)
Is there a way to send Bitcoins completely anonymously?

There is no such thing as a send address in Bitcoin.  I've heard Electrum has a feature with a name like this, but it's misleading.  Bitcoin payments are often made to an address, but when you spend them, you don't encode any sort of address into the transaction---you just provide the information necessary to prove you controlled the private key that created the address that was paid in the previous transaction.
When you start Electrum for the first time, it generates a random 128-bit number (a number between 0 and 340282366920938463463374607431768211455) called a seed.  Electrum then turns this number into the seed phrase you see.  Each of the possible numbers has a different seed phrase.  It's an assumption of cryptographers than no one currently has the ability to try even a significant fraction of all the possible numbers (or phrases) to guess your particular number.

a. No. There is a mathematical relationship between your public keys and your seed, but it's another assumption of cryptographers that nobody can determine this relationship without your private seed.  (Specifically, they need a number derived from the seed called the chain code.)  So making Bitcoin transactions does not reduce your security.
No. As stated in #1, there is no from address in Bitcoin transactions.  Each of the transactions you create will reference one or more previous transactions where you received payment.
No.  Bitcoin is a pseudonymous system.  In order to receive bitcoins, you must have a public key.  In order to spend bitcoins, you must prove you control the private key corresponding to that public key.  There are ways to make it difficult for people to associate your Bitcoin transactions with your real-world identity, but (in my opinion) none of them are easy and reliable enough for Bitcoin novices like yourself.  I suggest you only use Bitcoin for transactions that you wouldn't mind becoming public at a later time.


Is the Lightning Network susceptible to man in the middle attacks? It seems like a man in the middle attack could be performed in a Lightning Network.

Let's say A opens a channel with B. If A manages to control all the connects B has to the bitcoin network (becoming a man in the middle), A can prevent B's attempts to propagate or publish refund transactions. In this case, A can send some money through B to another address A controls, then publish the original balance transactions. If A can continue to MITM B for the 10 days (or whatever) it takes for that transaction to go through, A would have successfully stolen all the funds A was able to convince B to transfer.

B could potentially become aware that either the blockchain data he's getting isn't valid or simply become aware the balance transaction has been published, but if he can't get on the bitcoin network to publish the refund, he's screwed.

Is this scenario possible?

Such an attack is not limited to just Lightning; it could happen with just normal transactions and normal Bitcoin usage. However performing such an attack is very expensive and unlikely. It would require A to control as much hashrate as the entire network has. Otherwise blocks will come slowly for B and eventually warn him if too few blocks are received within a given time frame. Furthermore, if blocks were invalid, B will ban A's nodes and find other nodes to connect to. A would also have to control B's internet connection in order to prevent him from connecting to other people and opening channels with people other than A.

Lastly, the lightning network has a minimum balance requirement (minimum must be kept for both parties after it has been met, but both parties do not need to start with the minimum in the channel) so B would not lose all of his money. There is also currently a maximum amount that can be put in a channel so not a lot of money is risked.


How can I manually add a receiving address in MultiBit Classic Wallet - disconnected during confirmation Open to any suggestions... (Original Question is below and am trying advice from the first answer)

I am in the process of looking at all the deleted files on the USB disk where MultiBit resides using recovery software. Trying to determine where and if there was ever any private key to recover it.

There appears that the private key was not deleted as there is none for that time period so it was not received before the disruption. I recall it only started the confirmation process. I used the wallet infrequently. Previous time being last year (2014). Since there was no private key, could I not reestablish the wallet as it was at the about or prior to the point in time of the disruption and have it complete or run the blockchain to get the private key? There are numerous wallet files which I can see all with time dates which were deleted that are recoverable. I assume that it the rolling backup wallet files perhaps? I can even read the contents of the text ones and am seeing the actual receiving address (that I wanted to manually put into my wallets list) it is in a wallet file that is still deleted and recoverable probably. Ive not done anything as Im trying to figure out what procedure to do in what order as far as un-deleting files. I dont want to make a bigger mess either.

In addition I have a second copy of the same wallet on another USB drive which had the key from last use prior to generating the new receiving address which was disrupted when conformation was just starting. That second USB drive I did run the blockchain on and it did not have that receiving address...only synchronized and brought the chain up to date.

I would like to attempt to recover but am still trying to think through what would be most likely to work to or highest probability of success. I was thinking to how can I reestablish the wallet at or prior to time of disruption (with that receiving address) and then see if it will show the coins confirmation then save so there is a private key. Does this make any sense? OR is there a better more likely to get success approach? Any suggestions appreciated. thanks

-----------The Original Question below--------

How can I manually add a receiving address to my multibit classic wallet? Corruption of info file destroyed that address. After restoration back to last good copy, the receiving address (which I sent to the exchange) is no longer listed in my wallet in the list of receiving address in my multibit wallet. Due to an interruption in transfer during confirmation or power outage or usb disconnect (take your pick) that address disappeared.

The info file for that one time is totally corrupted from the power interruption. That probably explains the loss of the receiving address. My question and I should probably have been clearer about asking is "how can I manually add a receiving address to my multibit wallet receiving address list??" I know the receiving address and the precise amount as I sent it to the exchange and I can see it on the blockchain as one transaction...Just am missing the receiving address in my wallet and as I was watching it be confirmed when the sudden interruption happened before the key export or clean exit could happen. So I now have the address missing from the wallet list. The info file for that was totally unreadable and corrupted. I restored from the prior one. That was ok and ran the blockchain again. However that put me back in time before the new address was generated. The address was not there of course because of the info file corruption which has the address list and payment.

My question is how to manually to enter a receiving address into multibit wallet receiving address list? Can I put it into the info file? Tried it and didnt work... so please help.

How can I restore a specific missing address back into my wallet?? As I believe it would then reappear and complete the transaction if it was back on my address list. Thank you

You may have the receiving address in one of the rolling backups.
Also, if your wallet is encrypted then when you create a new receiving address then an export of all the private keys is performed automatically (encrypted with the wallet password).

Where all the files are stored is described in:
https://multibit.org/en/help/v0.5/help_fileDescriptions.html


Mt. Gox losses for tax purposes If I put $50 into Mt. Gox in February 2013, made multiples trades from BTC to USD and back, always remaining in the Mt. Gox system, and then lost all of it in the March bankruptcy, how do I handle that for tax purposes?  Do I have to pay taxes on money I never had?

There's no record of transactions since the site has been shut down.

As the final bankruptcy has not taken place, you don't know yet what you lost.  There could be some partial recovery paid to accounts.

Eventually the bankruptcy will be finalized, you'll get access to records, and you'll get the final determination of what was lost.  You'd claim your loss in that tax year, not 2013.

Edit: I see in your question you also might be wondering about paying taxes on any gains. If you have records, unfortunately you'd have to claim those as gains in the 2013 tax year.  If you have no records, you have to estimate using your best judgment.


Is mainline Bitcoin planning on switching to deterministic wallets? Deterministic wallets enable reliable backups but the mainline client doesn't use them.  I was told that bitcoind and Bitcoin-QT are planning on switching to deterministic wallets by default, is this correct?  Any idea of when?

It seems very likely, however it also seems to be a fairly long-term goal with no ETA as of yet: https://github.com/bitcoin/bitcoin/issues/5761


Signrawtransaction is not working on bitcoin core V0.17.1 I am having trouble signing a transaction on bitcoin core since it appears signrawtransaction no longer works.

I get the following error message :

signrawtransaction is deprecated and will be fully removed in v0.18. To use signrawtransaction in v0.17, restart bitcoind with -deprecatedrpc=signrawtransaction.
Projects should transition to using signrawtransactionwithkey and signrawtransactionwithwallet before upgrading to v0.18 (code -32)

Any advice on what to do? tahnks in advance!

As the error message says, signrawtransaction is deprecated. Stop using it. Instead use signrawtransactionwithwallet (if the transaction you are signing uses keys from your wallet) or signrawtransactionwithkey (if you are specifying keys on the command line).


Is it possible to keep bitcoind running with the blockchain synced up to only a certain height? I am currently using bitcoind to do some transaction analysis on a small part of the blockchain. However, after the local copy of the blockchain reaches the -stopatheight value, it quits. Is there a way to keep it running at that height? Or do I need to sync the full blockchain to keep it running? I want to keep it running so that I can run the bitcoin-cli and perform a few RPC calls

You can run with -connect=0. If it's not connected to anything, it can't sync further.


Multibit balance does not match blockchain balance. Weird extra bitcoins appear. Now the are gone plus some? So, really weird. Went to send some bitcoins to another of my wallets and all went as expected. I sent 1.013 BTC from a balance of about 3.01254367 BTC. My girlfriend then went to make a withdrawal. She said the balance was just over 4 BTC before the withdrawal which it couldn't have been because of my last transaction. It should have been just over 2 BTC. She said she sent 4 BTC leaving about 0.5 BTC in wallet. The transaction stuck, that was when I got involved to sort it all out!

I reset the blockchain and transactions on multibit and now the balance is 0.97 which doesn't seem to match up with anything? The transaction has shown up on the blockchain at all but I'm down by about 1 BTC.

What version are you on ? If you have earlier than 0.5.9 I recommend upgrading. The latest code also picks up pending transactions when you do a reset.

Also, you might want to do a reset blockchain from before when you created the wallet to make sure you have all the transactions on the blockchain.


Geting back transferred Bitcoins when the opposite party denied to accept the transfer I have sent some bitcoins to Payza Account, but Payza denied the transaction saying that the transfer shall be made through "Add Funds".    Now the Bitcoins are not showing either in my Bitcoins account or Payza Account.

How can I getback those bitcoins into my Bitcoins Account.

I think your best bet would be to contact their support and see if they can help.

Bitcoin transactions can't be "cancelled" or "refunded" after they get confirmed. Only the person that owns the address that you sent your BTC to will be able to send you your coins back.


How accurate should pool estimation of hashing speed be? I'm playing around with a few USB miners, and am running 4 of them for a total of 4.6 GH/s.  My BTCGuild dashboard estimation is all over the place, sometimes 1 GH/s, sometimes as high as 3.8 GH/s.  Overtime I expect it to converge to some value, but that hasn't seemed to happen.

It's my understanding that this number is just an estimation and will be affected by stale/duplicate shares my machine submits, but how stable should this estimation be?

Is the volatility of this estimate a product of the PPLNS scheme or could there be something strange with my setup?

How does my difficulty setting with the pool factor into this?

This happens with all pools. Some pools measure over a long time and get a fairly accurate hashrate, but it is very slow to react to changes (stop mining, add hashpower, etc.). Other pools measure over a short time and get a more inaccurate hashrate, but one that reflects changes faster.

The estimated hashrate isn't affected much by rejected work, unless you have an abnormal amount of those. If you have a lot of hardware errors (miscalculations) from your devices, those can also affect it some. These two issues can give a persistently lower hashrate than you are actually hashing with. But the source of the swings up and down is primarily the randomness with finding proofs of work. Some nonce ranges you scan will contain 3 and some won't have any at all.

Mining with a higher worker difficulty will increase the variance with finding proofs of work. If you set a worker difficulty that is very high for your hashrate then the website's estimate of your hashrate will likely be all over the place.

For a more accurate estimation of your hashrate look at your average hashrate per shift or other longer term, rather than a live hashrate estimate.

So there is really no specific answer to how accurate an estimated hashrate should be. Different pools use different methods, and some even have different hashrates in the same pool (measured over short and long periods of time).


When walletnotify and blocknotify notifications are sent out? Do the notifications from walletnotify and blocknotify are sent during the wallet synchronization or at the end? Say the wallet was offline for 100 blocks and when started: will it send the notifications after the each block it downloads and verifies and so all the relevant transactions in them or will it send them at the end? I would assume it sends them as it gets them, so then how would I resolve these properly if all the incoming request at that time are blocked?

Refers to Bitcoin Core 0.17:

WalletNotify

Will be executed at the time when a transaction gets added to the wallet. If your wallet is 100 blocks behind and in those 100 blocks you have 2 transaction in each block, the wallet notify script will be called twice per block (== 200 executions during the 100 block catch up).

Only valid blocks (valid transaction) will result in a wallet-notify call.

Will also be called when a mempool transactions (unconfirmed transaction) was added to the wallet (and therefore relevant to the wallet)

BlockNotify

Will be executed when a block gets connected to the active chain and before WalletNotify.

Consider taking a closer look at Bitcoin Cores ZMQ API that allows more efficient process interaction (wallet/block notify spawn a process on each call).


Insight-api: Websocket "tx" event - which variables? the Insight API has a websocket and publishes TX events as described here:
https://github.com/bitpay/insight-api (see bottom of this page)

The documentation says the names are:

  tx: new transaction received from network. This event is published in
  the 'inv' room. Data will be a app/models/Transaction object. Sample
  output:

{
  "txid":"00c1b1acb310b87085c7deaaeba478cef5dc9519fab87a4d943ecbb39bd5b053",
  "processed":false
  ...                        <------------- ?????????
}

There is literally a "..." and I dont know the other names of the websocket!

How do I know the other names execpt txid and processed? There has to be some addresses, value and so on. Where can I find a list of these outputs?

What you are looking for is in the lib\transactions.js file. Line 210 to 215.

  var transformed = {
    txid: transaction.txid(),
    valueOut: valueOut / 1e8,
    vout: vout,
    isRBF: isRBF,
  };

I took a quick glimpse, vout is an array and isRBS is a boolean.

Honestly, I don't know why "processed" is in the documentation example. I might possibly have overlooked it, or maybe it could be a local produced string.


Who will be the future miners? We know that the bitcoin for mining a block is going to converge to approximately zero as the number of bitcoins will be almost constant after a certain amount of time. So, mining will no more profitable in the future and if no one is going to maintain the ledgers then how the bitcoin going to survive?

If mining isn't profitable, fewer people will mine. That means the difficulty will drop, increasing the profitability of mining. That means more people will mine. The system is, by design, self-regulating.


How do exchanges decide on cryptocurrency trading pairs? Cryptocurrency trading pairs for example ltc/btc, doge/btc should be paired using some criteria. I'd like to comprehend on what basis they are paired.

Exchanges generally choose a few base currencies and build trading pairs on top of them. It has multiple reasons:

The exchange needs to find a base currency where people can understand the value of X from X/base. BTC/USD is $1350 that gives you a clear idea of how much BTC is worth in USD. That is different from LTC/DRK = 0.98. What did that tell you? Not much. You are in need of a base currency you are familiar with. Most people have a good feeling for the value of USD. Therefore, it is a good denominator.
The exchange needs to find a base currency which people are most likely to deposit/withdraw for trading. After you are done with trading numerous altcoins with each other, you want to exit the trading platform in a currency that has a meaning to you. To make that easy, base pairs are usually BTC.
This is probably the most important, if an exchange has BTC LTC USD, they will most likely not create BTC/LTC pair because that will decrease the liquidity of LTC/USD pair. They will most likely only offer BTC/USD and LTC/USD. On top of that, the extra pair will have maintenance cost to the exchange.


CPU Mining Test with CGminer After my boss read the websites mining on visits he got the idea to use the entire network we have access to. I have access to 3000+ computers and have been give permission to run a test over the weekend. Some of these computers have GPU's some don't. I would like to run cgminer with the --enable-cpumining flag to allow the cpu to work on the computers without GPU's.

when I use the tag

--enable-cpumining

I get

--enable-cpumining: unrecognized option

I think I am missing something here, any help would be great.

Q: What happened to CPU and GPU mining?

A: Their efficiency makes them irrelevant in the bitcoin mining world today

and the author has no interest in supporting alternative coins that are better

mined by these devices

from https://github.com/ckolivas/cgminer/blob/master/README


How do I receive bitcoins for a game server? I want to sell digital goods for BTC.

AFAIK, I have to associate the purchaser + BTC amount + address received + digital good.

I could set up multiple addresses for each client. If I kept a consistent address I would have to vary the fee to distinguish between purchasers.

How do I monitor the blockchain to process transactions - any known tools for this?

I've fiddled a bit with the plain vanilla reference bitcoin client, with the JSON-RPC server enabled, and it's all there. You can create accounts, so you can pass an address per user they can wire BTC to, query if any funds are there already (with a minimum number of confirmations), even pass the money on, to other local accounts, to remote addresses (other users or your cold wallet)

https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list


Does GNOME or KDE desktop enviroment matter, at running a BitcoinCore node? I have just installed Debian 9 (my first linux OS), and I am now choosing my Desktop enviroment. I have doubts at choosing between GNOME and KDE.

I know that both are conpatible with BitcoinCore, but my concern comes from the UI differences. The KDE and Bitcoin Core UI are both runed by Qt and GNOME is runed by GTK.

Does this have any significance?

The particular desktop environment does not have a direct impact as long as you have the necessary libraries for running Qt applications.

On Debian (or Debian-Based distributions, such as Ubuntu) the following command should install the dependencies necessary for the UI:

sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler

Those are the packages used by the bitcoin-qt package. Source


Proof of address ownership This question appears many times on SO, but there's something in the answers I'm not getting.

I'm designing a system predicated upon API calls made to blockchain.info, but I'm having real trouble getting my head around the relationship between Pubkey, Address and digital signatures for my use-case.

Say user Jane has previously transacted using Bitcoin and we assume the transaction is confirmed on the Bitcoin blockchain. Jane now makes a request from her app-based wallet software for some metadata concerning that specific transaction via the system's web-service.

The web-service requires Jane to prove that her wallet really instigated that transaction in order to permit her wallet access to the data, but here I get a bit hazy: From all my reading over the last 6 or 7 days, I gather the wallet software would need to sign some pre-determined message containing e.g. the TXID using the wallet's private key, sign it and send it to the system along with the public key, but once the system receives the data, and can verify the message using the public key, so what? How does that prove the txid (or address or whatever) in that signed message, was signed by the same private key from which the transaction in question is indirectly derived? There's some part missing for me that "reconciles" remote blockchain data with the data sent from the wallet app.

I understand basic PKI and that addresses are hashed derivations of a public key, but the digital signature part is messing with my head.

Thanks for reading. Any help would be greatly appreciated.

I opened random transaction for this example: https://blockchain.info/tx/c929454d6c83c15ecd9931c005a5a7fbacb1faba69f0a49538ab334d2848c5a1

Input scripts:

ScriptSig:
PUSHDATA(72)[3045022100eb1d36c6fe6c201e5594d90a7bdc73dd9a33d291e7e58ba74fec46ab2139c9c602207a7124819f9a004a36a0a2ac494603cfeecf38b8c12b3c6e3ff6dea74053706101]
PUSHDATA(33)[033f2223c8f6b74e75e4afd05811b8c9f55c8584abef768336e6ad61d931bef548]

First hex-value is signature of transaction. Second value is public key (elliptic curve point). And from this value we can derive address.

If you have another signature that signs something, and this signature has the same public key, that proves, that this is the same guy, who did transaction. Only one who have private key can sign something.

Elliptic cryptography works in the next way: we choose random number, and this will be private key. Then we multiply this number and EC point called generator, and we get public key.


What is meant by "Maintenance" of a Crypto Currency Wallet? I have invested in AltCoin XtraBYte XBY on c-cex.com exchange. My account now as XBY funds frozen because the XtraBYte Wallet status is on "Maintenance".
see https://c-cex.com/?id=ws
Where maintenance is a pretty straightforward word that is clearly understood in English, it remain another thing when we are talking about a cryptocurrency wallet. What exactly do we mean by an account on maintenance? What does it involve? Why a wallet would need to have maintenance? Why would users account be frozen because of a currency under maintenance?
Thanks for your help

In order for the exchange to process deposits and withdrawals, they must have an actively running instance of the coin's daemon, which is connected to the primary chain of the altcoin's network (i.e., not on a fork).

Wallet maintenance implies one of several possible things could be happening:

The exchange wallet is not on the correct fork, and needs to be
synced to the proper chain.
The wallet has been updated by the developer and the exchange is in the process of implementing the wallet update.
The wallet daemon on the exchange's server has hung or crashed.

There are likely other possible scenarios, but the general story is always the same: an exchange with a wallet marked as "maintenance" does not have an actively synced, running client of the altcoin available to the customer at that time, and has disabled access to the wallet to prevent customers from placing requests which cannot be completed.

Because the amount of each customers' funds is kept in a database hosted by the exchange, they are able to process trades for a coin despite the wallet being in maintenance.


I have 8 Antminers, is there a way I could change their pool credentials all at the same time like through ssh with a script As title says, I have 8 identical mining machines I just want to be able to point them at the same pool all at once, is this possible with a combination of python and ssh?  If someone else already invented something could you point me to that?  If not, could you give me a basic idea on how I would tackle this myself?

Here are the instructions for setting a mining proxy which allows all your miners to connect via the proxy instead of via their own config.  This way you only have to stop then start a single process on the proxy to change pools instead of messing with each miner to do the switch.

Setup mining_proxy.py on a linux machine

pont slush's mining_proxy.py at a pool of your choosing using a bash script file (remember to chmod 755  so you can run the bash script with ./)
setup each pool you want to mine with it's own script (same -sp (port)  for each )
point all your miners at the proxy server with the port you are using
make sure all pools use the same worker names and passwords (since this is setup on the miners)
start your chosen bash script (best to use screen so you can exit the session and leave it running)
miners can be switched by ssh via screen -d -r , then ctrl-c (to kill the proxy), now just run the correct bash script to switch to the next pool.


What's going to happen if someone has access to my Bip32 root key? Can my bitcoin get stolen if someone else has access to my Bip32 root key?

Assuming we are talking about the root private key (xprv) then yes, he will be able to steal all your current and future coins as long as you keep generating addresses from that key. It’s basically the same as him having access to your mnemonic phrase.


Bitcoind could not locate RPC credentials but rpcuser and password are set I installed bitoind and synced it. But when i'm trying to connect from my php website i getting:
Unable to connect to http://user:password@my.bitoind.server.ip:18332/.
Also when i'm trying to see password through command

bitcoin-cli -stdinrpcpass getblockchaininfo

it returns

could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/blockchain/.bitcoin/bitcoin.conf).

My bitcoin.conf file is setted and works nice

rpcuser=USER
rpcpassword=PASS
testnet=0
daemon=1
rpcport=18332
rpcallowip=*
server=1
datadir=/blockchain/.bitcoin
txindex=1

I found I had to copy the contents of ~/.bitcoin/bitcoin.conf into /etc/bitcoin/bitcoin.conf because that's what's being used when bitcoind starts on boot up. I put my user and password in that file, rebooted, and bitcoin-cli worked again.

Also try adding

bitcoin-cli -stdinrpcpass getblockchaininfo -rpcuser user -rpcpassword password


Can you inherit bitcoins without the private key? Since the private key is needed to validate ownership, how does it work when you cannot access the private key?

Say X owned bitcoins and willed it to Y, but Y does not have X's private key. Say X's estate does not want to to give access to the private key or the location of the private key is untraceable.

Y can't spend the Bitcoins. You need the private key for an address to spend the Bitcoins from that address. There's no way around it.


How a new wallet knows balances locked in P2SH transactions? If my old wallet created and submitted a P2SH TX to the blockchain, and I migrate to a completely different wallet, how can the new wallet detect that that UTXO belongs to me? Since the script is hashed, it can be anything and contain unpredictable information, like other PKHs in multisig transactions

In short, it knows because it knows. Whatever information was used to make the original wallet construct the addresses (whether that consists of a seed, a set of keys, a master key, a descriptor, a mnemonic phrase, ...) must be imported into the new wallet too.
The P2SH redeemscript is not created randomly: there is a procedure to generate it from keys the wallet has, and those keys may themselves also be generated from such information. What that information is depends on the standards or schemes involved, so it's hard to be very specific here.
Deterministic wallets have been standard since 2013 or so, and pretty much all wallets have some means of deterministically constructing keys from some fixed immutable piece of data. For single key policies (simple wallets) a wallet also needs information to turn those keys into scripts/addresses. Common ways include P2PKH (address contains a hash of the public key), P2WPKH (similar, but uses segwit for spending), or P2SH-P2WPKH (where the address is a P2SH address containing the hash of a segwit program that contains the hash of the public key). The wallet needs to know which (possibly more than one of these) is used to convert the keys into scripts, and that implies also a way for computing the redeemscripts involved. Sometimes this choice is implicit in the standard being followed; sometimes it needs to be imported/chosen specifically.
For multisignature or other policies it is more complicated, as wallets also need to know how the other participants generate their keys, but this information is always needed - both in the first and the second wallet.


In the Lightning Network, what happens if a "middle node" suddenly goes dormant for a long while? I think I have a general understanding of how the Lightning Network works. However, I was having a little difficulty in understanding what happens when a node in the middle of a "path" suddenly goes dormant, or offline for a long time. To clarify my question, consider the following example:

A wants to make a payment of 1 BTC to D.
A finds a path from A --> B --> C --> D.
D generates an R and sends H = hash(R) to A
A creates HTLC of 1.002 BTC with B.
B creates HTLC of 1.001 BTC with C.
C creates HTLC of 1 BTC with D.
D unlocks HTLC, receives 1 BTC, and then tells R to C.

However, what if C is suddenly offline meaning C won't be there to receive R from D and thus stops the flow of R back through the path. I would assume that the HTLC's between A and B and B and C run out and so A and B are refunded.

So, would C lose out? Would A have just made a "free" transaction? I assume this is a fast process, but is it likely such an event occurs where a middle node in an LN transaction just goes down for a long while?

If the transaction cannot resolve before the CLTV value of the HTLC runs out the peers will be refunded (the pending HTLCs cancelled) and the transaction will be cancelled.
If C is not there to receive R funds will not move so there is no need for force closures, but the funds will be stuck on the online channels as well for that period of time.
The online channels will be able to propagate payments in the meantime given there is more liquidity available and the number of pending HTLC-s is below the set limit.
See the situation where C would be online to receive R and go offline before propagating to B discussed in:
What happens if R is not revealed by one of Lightning Network nodes? (Payment cancelation)