Repeatedly sending coins from an address to itself Let's say I create an address that has a balance of x bitcoins, where x is the minimum transaction amount before prompting a fee. Hypothetically this address is used as a permanent cryptographically secure mechanism that sends itself x coins at certain points which have some significance.

Will miners mine this transaction over and over or will it eventually be ignored by the network?

Will this transaction be readable by parsing the blockchain, or is it handled differently?

Will this transaction ever eventually incur fees and thus never be put into a block (since the wallet will never own more than x BTC)?

Nodes don't check the history of a coin or address to determine whether to include or propagate it, so it will be possible to send coins from an address to itself multiple times.

However, the priority of a transaction depends on how aged its inputs are. If you try to do it too frequently, you'll be using young inputs, lowering the priority and making a fee necessary.


How can I see if my bitcoin core money is in my wallet? I had funds deposited in my bitcoin core account about a year and have still not seen them appear in my wallet. Is there a way I can make sure the transaction went through, and how I can have access to the funds? I have the receiving address where the funds were sent to. Thank you

If you haven't seen them appear you may be seeing one of two problems:

Your Bitcoin Core application is not synchronizing with the network properly
You deposited your Bitcoin to a wrong address

I would find out where the Bitcoin is on the blockchain to be sure; only if you remember the sender of the Bitcoin. You can read up on the technicality of Bitcoin here.


Can a transaction disappear? (Orphan Blocks) Can a transaction disappear after transfers transactions to Bitcoin networks.

I heard about the Orphan Block.
Are all transactions in the Orphan block going away?

Is there a possibility that transactions will be lost in bitcoin network?

When a block, or set of blocks, is dropped (orphan block, minor fork, chain reorganization), any transactions in those blocks are returned to the mempool. Usually, many of these transactions will be contained in the blocks that replace the dropped blocks, and end up in the chain anyways.

It is relatively rare for a transaction to outright disappear, and will never happen for a transaction with sufficient confirmations. It is not unheard of for transactions with very low fees to be evicted from the mempools of enough nodes to be lost entirely during times of network congestion, however.


Does Bitcoin still use the IRC channel? I recently read an article on Bitcoin Media, that claimed:

  Jeff Garzik pointed out that Bitcoin-Qt no longer operates using the IRC bootstrap, and on inspection he’s right. This mainly applies to older versions of bitcoin.

Implying that the IRC channel is no longer used by Bitcoin-QT. Is this true, and if so, which version of the standard Bitcoin client was the first not to use the IRC channel?

The IRC bootstrapping method is deprecated and default off since the 0.6 release. It's still implemented and can be enabled using the -irc command line option.

The function of the IRC bootstrapping system will get replaced by DNS seeding and peer exchange, however.


Is mining the unfair part of bitcoin in the same way banks (or rather, fractionary reserve systems) are to current monetary system? I've been reading a lot about bitcoin lately and I'm very interested.

Especially, when it comes to making a currency that is way more fair, because it avoids a centralized control of it.

However, in the same way today's banks/centralbanks/FED/regulators benefit from how the current monetary system works, wouldn't an economy solely based on bitcoin make the big IT corporations take advantage of everyone due to their computing (mining) power?

Cannot we build a currency that is decentralized like bitcoin, but that doesn't have the "mining" part of it? (I know that mining concept is very tied to cryptography, but maybe a less cryptographic-centric system can be built, like one based on trust/untrust between nodes?)

Thanks very much, and sorry if this has already been asked, but it's difficult to look for a question like this.

Question: Cannot we build a currency that is decentralized like bitcoin, but that doesn't have the "mining" part of it?

No need to, one was already created years ago and is still up and running today. Bitcoin depends on currency creation to record transactions, you can't get around this because that is the design of it and how it works. The only one that approaches this in a different way is Timekoin. Transactions and Currency Creation are separate. Transactions can be processed like clockwork every 5 minutes with no currency being created, provided some currency already exist to spend. Currency Creation is also produced like clockwork in very small amounts. So anyone running the server software can create currency, but in a very gradual, controlled amounts as long as the strict rules are being followed.


Risk of a certain machines being compromized Is it possible for a sinister entity to peek into the p2p network of bitcoin and manipulate it in such a way so as to compromise a certain transaction?

No. However a machine with that person's bitcoins on it can be compromized and their bitcoins can be stolen.


Information to recipient of the transaction I have some questions of the transactions bitcoin,

In a transaction bitcoin, there is not information on the recipient, right?

How do services such as blockchain.com track information about a transaction, from which wallets have they started and to which wallets have they arrived?

Block explorers know some information about wallets because they belong to public entities with known addresses.

Other wallets are known because Bitcoin wallets typically follow a spending pattern where it's very easy to link together outputs and inputs belonging to the same wallet.

For example:

in most transactions all inputs belong to the same wallet
if a transaction has one output of 0.5 (or any other round number) BTC and one output of 0.158293 (or any other non-round number) it's likely that the second output is machine generated and belongs to the wallet of the sender


How do you sweep a paper wallet with Bitcoin-Qt? Sweeping involves importing a private key, then sending it's entire balance to a new address in your wallet via a new transaction.  This would protect your paper wallet's bitcoins from being stolen if someone else ever had access to your paper wallet, or obtains access to your paper wallet in the future.

I'd love to know all the nitty-gritty steps involved with Bitcoin-Qt.

Unlock your wallet
Run Import Command in Debug Window
Sweep to another key

https://en.bitcoin.it/wiki/Help:How_to_import_private_keys_in_Bitcoin_Core_0.7%2B

Tools needed: camera in your PC + qr code reader.
But of course you can find the private key value with classical mathematics ;)


Wrong Adress Blocking System for Transfers I want to withdraw my BCH (BCC) in Bitfinex to transfer to Bittrex. I selected BTC to deposit address. In conclusion I sent wrong currency address. There is no system to warn us "You input wrong currency address".

Can anyone guide me to recovering the coins?

This is technology but inside of this, there is no system to warn us "You input wrong currency adrress".

That is because Bitcoin and Bitcoin Cash addresses are completely indistinguishable (Bitcoin Cash copied Bitcoin entirely which includes the address prefixes). There is no way for a system to warn you that you entered the wrong address because both are valid Bitcoin and Bitcoin Cash addresses and there is no distinction between them, i.e. a Bitcoin address is a Bitcoin Cash address and vice versa.

The only thing you can do is to contact Bittrex and see if they can do anything. In theory they can because they control the private key for that address and Bitcoin and Bitcoin Cash private keys share the same identical-ness properties of addresses.


Why are Bitcoin transactions sometimes confirmed instantly if blocks are mined every 10 minutes? I have a basic question on Bitcoin and blockchain:

Sometimes transactions are confirmed almost instantly, but there should be a new block every 10 minutes, so how is it possible? A transaction can be confirmed only after being included in a block, right?

thanks!

A little more information is necessary to tell you exactly what happened to your transactions that were confirmed "almost instantly" but what you've said is correct:

The bitcoin protocol is such that new blocks should be mined, on average, every 10 minutes.
A transaction is "confirmed" (has 1+ confirmation) only after being included in a block. Before this, the transaction is "pending". Some merchants require more than one confirmation for the transaction to be final, many choosing to wait for 3 confirmations before being deemed complete.

However, the situation can arise where after publishing your transaction a block is then mined a few seconds later that has your transaction in it. This could give the appearance that your transaction was confirmed "almost instantly".

Possible source of confusion: Blocks aren't mined 10 minutes after your transaction, they're mined 10 minutes (on average) since the previous block was mined.


What can be done to slow/prevent mining centralization? Assuming all buyers have access to the same ASICs (ignoring that ASICs developers and manufacturers will always have the latest first, even if only used for "testing" prior to sale) energy costs would seem to promote a long term trend of mining in areas with the lowest relative costs.

I believe in the PoW model and am not interested in PoS solutions. What can be done to slow/prevent centralization in areas with the lowest energy cost?

Asking how to prevent the mining industry from being centralized into places with low electricity costs is like asking how to prevent the shipping industry from being centralized into cities that are on the coast.  Both industries will tend to thrive in places where the profit margins are highest...and there's no profit margin in building a port in a land-locked city.

Since we are assuming that access to the latest ASICs is uniform for all contenders, profit margins are determined by electricity costs.  However, remember that running the ASICs isn't the only thing that miners do that costs electricity.  Cooling the ASICs is probably the larger electricity cost, just like it is in most data centers.  Given two locations with the exact same electricity cost, but different average temperatures, the location with the colder temperature would prove to be more profitable.  It would cost less electricity to cool the ASICs.

Now the problem seems to be mining centralizing into locations that have both low electricity costs and low temperatures.  However, the second factor does create a variation in the trend.  There are some locations that may have higher electricity, but are so cold that they don't have to use that much of it to cool the ASICs.  There are other places that may be warm, but have such low electricity costs that it doesn't matter.

I'm fairly sure your question doesn't have a simple answer, but be reassured to know that there is at least another factor that will affect the trend.


Hash rate, transaction and block relationship I'm aware that when the hash of the block header (block hash) is below the difficulty target, a block is deemed as validated.

But because I've never run a bitcoin node before (will soon), I had a few questions regarding the mining process.

1) When miners are running the BTC software, are they by default confirming transactions in the mem pool based on the highest fees, or are they allowed to choose which transactions they may validate?

2) If you have a higher hash rate, does this mean you can validate transactions quicker as well?

3) When a block is validated on average every 10 minutes, as set by the BTC protocol, are miners also trying to validate transactions too?

4) How are transactions validated?

Miners can choose whatever transactions they wish to include in a block, as long as they are valid, but doing so may require them using custom software. As far as I'm aware, the Bitcoin Core software selects transactions by highest paying fee first.

No. The hash rate is determined by specialized hardware (ASICs) which do not perform transaction validation. The hardware does not help with the validation of transactions because it would take longer to transfer the information to this hardware than to simply perform the hashing on the CPU. The bulk of the time in validating transactions is spent on signature validation anyway, which the ASICs do not do (although it would be possible to build one for this particular purpose).
The mining ASICs are mainly more efficient than mining on the CPU is because they perform the hash algorithm on the same data many times, internally only updating a random number for each hash attempt and recalculating the merkle root.

Miners validate all transactions as they come from the network just like every other network participant. Their bitcoin node will hold incoming transactions in the mempool, and the mining software will request a block template at regular intervals, containing all of the transactions which are to be included in the block. In a mining pool, the pool operator creates the block template and the miners work from that template, and validating themselves it is optional.

This is quite a complex topic because every single aspect of a transaction needs validating, and the entire details are not defined in a document, but by the reference implementation (the satoshi client / bitcoin core).
The key details are that:

All of the inputs to a transaction are checked to be unspent
The sum of the output amounts is less than the sum of the input amounts (with the difference being the transaction fee).
For each transaction input, the scriptSig from that input is pushed onto a stack, then the scriptPubKey from its matching transaction outpoint is evaluated with that stack. The script must evaluate to true for the transaction to be valid. The scriptSig will usually contain a public key and a signature, and the scriptPubKey will usually perform an OP_CHECKSIG, which tests that the SHA-256 of the entire transaction was signed by the private key matching the public key. (This itself is quite nuanced because the transaction must be stripped of the signature before it is signed or validated).

There are many finer details to the validation of transactions, which are mostly answered in existing questions on here, explained on the bitcoin wiki or in the BIPs.


How does the "failover" setting in cgminer work? I have been messing with a p2pool which I like (no fee) but has latency about every week causing the miner to stop mining altogether. I would like to employ some kind of failover strategy so that the miner will mine somewhere else if unable to connect to this free p2pool, but I would like to be mining on the primary pool as often as possible.

I have tried looking at the multipool settings, but they weren't very informative in terms of what happens when. If I set failover does that mean that it will only connect to the second if it can't connect to the first? If not, is there any way to set up cgminer this way?

Yes, the failover setting will tell cgminer to mine on a secondary pool when the first pool is unavailable.
Run cgminer with the following:

  cgminer.exe --scrypt -o http://p2pool.org:9327 -u username -p password
  --failover-only -o http://backuppool.org -u username -p password

This example mines LTC  at p2pool and will mine at another pool of your choice when p2pool is unavailable.


Why is not Bech32 address selected as default in Bitcoin Core 0.16.0? So, thankfully Bitcoin Core 0.16.0 came to us, general people.

But however, native segwit address Bech32 wasn't selected as default.

Is not it better to use a Bech32 address right away rather than P2SH segwit-wrapped address?

Bech32 Addresses is still not supported on the other platforms. There are many libraries even considering bech32 address as "invalid."

If I'm using Bech32 address and asking someone who is using another platform to send me some bitcoin they may never be able to make the payment.

We need some time so it becomes supported everywhere.

Right now Blockchain.info, Electrum doesn't support bech32 address and they're highly used.


Can casual people still mine for bitcoins, now that the difficulty is much higher than it was? Can casual people still mine for bitcoins? As of October 2012, the difficulty seems very high, being over 3,000,000.

I've seen a ad for bitcoins, and watched the video. It said I could mine for them with my computer, so can I?

Well, you can TRY mining. To see how much coins you can expect, check your computer's GPU on the Wiki page, get its hash rate, and plug that into a profitability calculator, such as mine. This can give you an idea of how many coins can you expect to mine and whether you would get any profit from that.

Unfortunately, most likely you won't be able to mine at a profit using a PC. Bitcoin's difficulty is quite high, the reward will be dropping by half soon, and with the introduction of ASIC miners, GPU mining will be outclassed. However, if you are willing to invest some money into custom hardware, you can still start your career as a full-time Bitcoin miner. But again, you ought to check if it calculates for you.

However, if you want to try your luck at a newly emerging trend of using your GPUs to "mine" for split-key vanity addresses, you can check out my Vanity Pool, or its topic on BitcoinTalk. The process is quite similar, but the profit margin can be better.


Getting or Building coinbasetxn to create the Merkle Root My goal is to make my own bitcoin miner (in Go). But I am having an issue:
I am not getting coinbasetxn in my getblocktemplate request.

curl -u user:password --data-binary '{"jsonrpc": "1.1", "id":"0", "method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "workid", "coinbase/append"]}] }'   -H 'content-type: application/json;' http://127.0.0.1:8332/

Fields in result:

coinbaseaux
previousblockhash
target
noncerange
transactions
mintime
sigoplimit
curtime
capabilities
height
version
bits
coinbasevalue
sizelimit
mutable
longpollid

So I am assuming I have to build it by myself.
What are the steps to do so please? Thanks a lot

The coinbasetxn is a field that results from a request from a pool. Have you seen this link here? How to compute merkle root without coinbasetxn?

You are hitting your local block chain node which will give you the actual individual transactions in the transactions field. You can then use all the fields to create the coinbasetxn yourself.

To build it yourself, I recommend reading example/actual code in another language in conjunction with the docs. Check out this link: https://www.anintegratedworld.com/whats-in-a-block/ where you can read the wikipedia links and also see graphically the internals of a block.


How to get an average bitcoin to USD price from different sources I created a very simple php function to get the current price of bitcoin to USD here,

    //get from coin market
$getCoinMarketPrice = getPrice('https://api.coinmarketcap.com/v1/ticker/bitcoin/?convert=USD');
$btcValues[1]= $getCoinMarketPrice[0]['price_usd'];
//get from bitstamp
//
$getBitstampPrice = getPrice('https://www.bitstamp.net/api/v2/ticker/btcusd/');
$btcValues[2] = $getBitstampPrice['last'];
//get from blockchain

$getBlockchainPrice = getPrice('https://blockchain.info/ticker');
$btcValues[3] = $getBlockchainPrice['USD']['last'];

//get from cytptonator
$getCtyptonatorPrice = getPrice('https://api.cryptonator.com/api/ticker/btc-usd');
$btcValues[4] = $getCtyptonatorPrice['ticker']['price'];

$total=0;
for ($i=0; $i < count($btcValues[$i]); $i++) {
    $total +=$btcValues[$i];
}
$average = $total/count($btcValues[$i]);
return $average;

This Code here above will get bitcoin prices from different sources and add them together and divide them by the total number of the source it got them from e.g

  bitcoin from source from blockchain and bitpay and Xapo are
  6000,5689,5997 respectively, so to get the average result we add these
  results and divide them by 3.

This code is working perfectly, but it's making my app very slow and sometimes Timeout.
Please I need it to be refined and better than this , Thanks

You would want to avoid doing this on every page load. Instead I would recommend making it a cronjob that runs every N minutes and dump the values into a database. Then for each page load pull from your database instead of fetching from external sources. This will make your page load faster and you wont have as many api requests. Most sites limit your number of requests and if you are pinging them every page load you might get blocked.


What is the difference in speed between a GPU and an ASIC per dollar of cost? I realize it depends on the ASIC as well as GPU.. Just want an estimate for some calculations I'm doing.

Talking about Bitcoin mining, not an altcoin.

Thanks!

The AntMiner S4 gets 2 TH/s and sells for about $1200. This is 1660 MH per second per dollar.

The AMD Radeon 5830 gets 307 MH/s and sells for about $200. It was released in 2010, so if we assume that graphics cards have doubled in power every 18 months, that suggests that the best Bitcoin mining graphics card on the market today gets 12.2 MH per second per dollar.

So they're on the order of a hundred to a thousand times less powerful per dollar.

This is a generalization.


How do I optimize my usage of oclvanitygen? I'd like to extract the most performance possible from oclvanitygen.  Can anyone tell me what the best practices are with this tool?

Examples may include:

Use operating system X, or video card Y
Ensure that the file specified with the -F option has more than 7 characters per row
Ensure that there are no more than Z quantity of lines in the file
Set a custom grid size with the -g option (what is this?)
How many work items per thread ( -w option)
What custom options should I use (-d option)

1) Make sure the Vanitygen you use has the AMD patch (if you have an AMD GPU, Vanitygen Plus has it)

2) Update your GPU drivers (can't be done on Mac)

3) Play with each of these constants. Their effect is different among the GPUs and drivers, and you may never know if they can have a (relatively) significant positive effect performance.

-w <worksize> Set work items per thread in a work unit
-t <threads>  Set target thread count per multiprocessor
-g <x>x<y>    Set grid size
-b <invsize>  Set modular inverse ops per thread


What does "Uneconomical UTXO requested" mean? I'm using the btc.com wallet and I want send 0.001 btc to another address but I'm facing this error: Uneconomical UTXO requested [type: 1 (limit 6831), txOut.val: 5897, required: 98140]
What does it mean? And how can I resolve it?

This error message seems to indicate that one of the Unspent Transaction Outputs (UTXO) in your wallet has a lower value than the cost of spending it.
In Bitcoin, funds are tracked in the form of distinct transaction outputs. Each time someone gets paid, at least one new transaction output is created. While your wallet may show your funds as a balance, under the hood the balance is actually composed of one or multiple UTXO. To spend a UTXO, an input is added to a transaction. Transaction fees are paid per byte of data. If an input for example used 148 bytes, and the current feerate were 100 satoshi per byte, it would cost 14,800 satoshi to spend a UTXO. If the UTXO's value was 5,897 satoshi, it costs more to spend it than its value— it is uneconomic to spend it.
You may be able to sidestep the error by setting a lower feerate. Note that this will likely cause the transaction to take a long time to confirm.
Altogether, it would be reasonable for your wallet software to filter uneconomic UTXO in the preselection, so you may want to consider reporting this as a UX bug.


How to specify PrivateKey search range in HEX? I am trying to generate random bitcoin Private_Keys in HEX format (32bit) but
I want the randomness to have a value within a specific HEX range, say between

18909BDE11F67C97A53C62F45E632EAB58EA0D73A5FAC9EB50295FAD40A57EB5

and

DD10559E1285B3EE0303B159B8D6D8D0B88E6168D1C1D6000000000000000000

The following piece of code in Python 3 is a start but it simply generates random keys for the curve's entire field which is up to

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

This is the code:

generate_private_key():
    return binascii.hexlify(os.urandom(32)).decode('utf-8').upper()

How to specify the desired search range expanding on the above code?

Thanks.

Use random.
Using your low and high values:

import random
def generate_private_key():
    low  = 0x18909BDE11F67C97A53C62F45E632EAB58EA0D73A5FAC9EB50295FAD40A57EB5
    high = 0xDD10559E1285B3EE0303B159B8D6D8D0B88E6168D1C1D6000000000000000000
    return str( hex( random.randrange( low, high ) ) )

And then just:

print(generate_private_key())

Note that you'll probably need to convert this hex address to wif, or extract a public key or bitcoin public address from it... If you need more easy Python code for doing this, you can check these little pieces of code.


ZeroMQ Notifications in Browser JavaScript I am trying to develop an online application primarily in JavaScript. As I am aware, the only way to receive notifications for unconfirmed/mempool transactions as they appear on the network is to utilize the -zmqpubrawtx or -zmqpubhashtx commands in the startup of Bitcoin-Core. I have setup one of these values to be the example -zmqpubhashtx=tcp://127.0.0.1:28332

However, I am having a difficult time implementing this in any browser based JavaScript. The only library that is not based solely on Node.js is JSMQ which does not appear to support tcp:// as the socket type (apparently relies on JavaScripts WebSocket which only lets you use ws:// or wss://). I am trying to avoid online API usage such as blockchain.info, etc.

My question:
Are there any other methods of receiving realtime unconfirmed transactions notifications (that don't belong to a specific wallet) and that doesn't rely on an external/online API? If there is no alternative, are there any known/reputable libraries available for ZeroMQ for JavaScript

If I understand this correctly, you're trying to communicate with Bitcoin Core through ZeroMQ directly from the browser.
This is not possible.

The reason why JSMQ only supports Websockets (ws://) is that browsers don't allow you to use raw TCP sockets. The only protocols you can access from within the browser are HTTP(S), Websockets, and WebRTC (which is still not supported everywhere).

In other words: the browser won't let you communicate directly through ZeroMQ.

If you don't want to rely on an external API, then you can always write your own and run it on the same server/computer where you are currently running Bitcoin Core.
This software should receive updates from the Bitcoin node through ZeroMQ, and send them to the browser via websockets.

As long as it supports websockets or HTTP(S) you'll be able to connect to it from within your browser.


How does P2SH unlocking work? "Mastering Bitcoin" by Antonopoulos in its P2SH section describes how the unlocking and locking scripts are executed and evaluated by nodes. The author gives this as example of an unlocking script:

<Sig1> <Sig2> <redeem-script>

and the locking script:

HASH160 <20-byte hash of redeem script> EQUAL

Then there's this:

  The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches: [...]

Questions

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.  Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?
If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?
Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?
Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have   a TRUE on top at the end of execution?

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.

Nothing uses the "concatenate unlocking and locking script and execute". That approach was abandoned in Bitcoin v0.3.7 (released in July 2010), as it was the reason for one of the two theft-enabling bugs Bitcoin had in its infancy.

The current approach is to first execute the unlocking script, look at the resulting stack, and then execute the locking script with that stack as initial stack. The resulting top stack item determines whether validation succeeded or not.

  Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?

It is not so much a different rule - just an additional rule. Because of backward compatibility, network rule upgrades can only add additional restrictions on previously-valid scripts. They can't make invalid scripts valid, as those would risk splitting the network in two (look up "softforks").

  If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?

Whenever a spend (a) validates using normal rules and (b) has a locking script that satisfies a specific pattern, defined in BIP16, an addition P2SH-specific execution follows, whose validation result is what matters.

  Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?

This same approach is used for a much more recent network rule improvement, called SegWit, specified in BIP141, which is expected to be activated on the network around August 22nd 2017.

  Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Yes, by definition, because P2SH only adds additional restrictions. The specific P2SH locking script just checks whether the spender knows the "embedded" unlocking script (also called redeemscript).


How specific are ASIC's design? Can they single hash SHA256? I understand that Bitcoin's ASICs are a highly optimized piece of equipment and, therefore, are also very specific.

My question: are they able to do a single (or triple?) SHA-256 hash at all? And, if so, how competitively would they be with versus a GPU?

A Bitcoin mining ASIC:

does not attempt to complete a single hash, rather fragments of two SHA256 compression rounds which is then compared to a target, the result is never returned
can not accept arbitrary information that is not in the form of a partial SHA256 compression round

So in terms of competitiveness, a CPU can actually complete a SHA256 hash, a mining ASIC can not, which I suppose puts it ahead in this arbitrary race.


How secure is calling bitcoind JSON-RPC from same computer? I am wondering if calling JSON-RPC from the computer it is running on is secure. I read How secure is calling bitcoind JSON-RPC? and understand why it is insecure to do so from a different computer.

Is there a secure way to call it from the same computer without using SSL?

Yes. By default, Bitcoin will only listen for RPC connections on local loopback. Local loopback cannot be accessed or spied upon by another computer.


Can R/r in Musig be derived from only seeds and message hashes? I am wondering if the first two roundtrips of pre-committing and then revealing R/r in MuSig signing can be moved to the keygen phase and made deterministic. That reduces the amount of messages that need to be exchanged; since keygen is done only once, we want to expand that phase. This would be especially useful for HD wallets: at the expense of making wallet creation more complicated, signing would need fewer interactions.

The musig paper on page 10-11, specifies the following (from perspective of signer 1):

MuSig scheme

Key generation

generates private key x1 and corresponding public key X1
sends X1
receives Xi

Signing (specifically the part about agreeing on Ri)

sends t1=Hcom(R1)
receives ti
sends R1
receives Ri
checks that Hcom(Ri)==ti

r1 is specified to be random.
Signing includes three rounds of interaction, two of which is used for the above steps (agreeing on Ri).
I want to move these steps to the keygen phase.

A HD wallet would presumably use BIP32 to generate X1.
Can we use BIP32 for deriving Ri/ri too?

Consider the following scheme instead.
(from cosigners 1's perspective)

Proposed HD scheme

HD wallet setup phase

generates xprv y1 and corresponding xpub Y1
generates xprv k1 and corresponding xpub K1
sends xpub Y1
sends u1=H(K1)
receives xpub Yi
receives ui
sends xpub K1
receives xpub Ki
checks that H(Ki)==ui

Key generation

from xprv y1 along some BIP32 path p, derive private key x1 and public key X1
from xpub Yi along same BIP32 path p, derive public key Xi
from xprv K1 along same BIP32 path p, derive private key j1 and public key J1
from xpub Ki along same BIP32 path p, derive public key Ji.

Signing (specifically the part about agreeing on Ri)

compute r1=j1+hash(m) and R1=J1+hash(m)*G
compute Ri=Ji+hash(m)*G

This approach only has one round of interaction during signing (sending si, omitted as its not changed from what is described in the paper).

I have read the derandomization section, but the explanation for why it doesn't work requires Ri to be chosen by the attacker. If we make it deterministically derived, and BIP32 is safe, then this attack does not apply. The paper states "each signer must ensure that whenever any Rj sent by other cosigners or the message m changes, his ri value changes unpredictably. As long as f is deterministic, this implies a circular dependency in the choice of random values."

Where is this circular dependency? The f from RFC 6979 only depends on key and m.

The construction you're suggesting will likely work as long as you don't sign more than one message. By effectively choosing the R points ahead of time, you've constructed a single-show signature.

However, the derivation you're using for the different R values is pointless. It's not enough that you don't reuse R values; you can't use multiple related R values either. All the R values you are constructing are related through a single linear equation. That is sufficient for an attacker (who knows about the relation) to derive the private key from seeing two signatures.


what is the fastest free way to get at least 1 satoshi I know CPU mining uses more power than its worth.  I know GPU mining uses more power than its worth.  Yadda yadda.  Regardless, I have a spare server, my home internet is on an unlimited plan, and electricity is included in my rent, so...

As a learning exercise, I have been running headless bitcoind for several weeks.  I have also run it on testnet3 at times, and used online testnet3 BTC faucets to get testnet3 BTC to my bitcoin-core testnet3 wallet.  I have also played with the command line RPC interface for querying the blockchain, the wallet, etc.

Now I would like to do similar with (non-testnet3) BTC.

However the faucet I tried is "giving" me like 23 Satoshi (within their internal account register) per captcha, with 1 h wait for next try, and 30,000 Satoshi payout limit, and 3,000 withdraw fee.  This will take 54 d if I visit it every hour 24x7.

And with the mining pool I tried (slushpool with bfgminer compiled from source with CPU, GPU mining enabled), I don't entirely understand the pool's nor miner's interface.  The miner claims to be working at 6 Mhash/s, while the pool at first seemed to be saying 0 hash/s.  But after 24 h, it seems to show 1 blip in its graph where there was momentarily 1 active worker, and the hash rate blipped up to 427 Mhash/s and then decayed back to 0 over about 1 h.  I suppose this represents the completion of 1 share but I don't see a way to set a lower difficulty than the default 128 (and haven't read enough about pools and shares yet to understand how that would help anyway).  The pool has a minimum payout of 0.1 BTC and thus estimates my time to next payout at 48 y.

What other free method can I use to get at least 1 Satoshi into my wallet sooner than the above?  Are there faucets or pools or other methods that are several orders of magnitude faster than this, such that I could complete my experiment in a day or two?

Note, please exclude answers that boil down to "mine altcoin and convert to BTC".  Also I've implied in my question (in addition to my hardware, electricity, and bandwidth being considered free) that my time, by mentioning faucets which mostly have captchas, is free.  However let's not extend that to "design a web site and charge in BTC".  And obviously not "buy BTC on exchange" as that is not free.  Also I don't mind if the transaction fee is exorbitant, e.g. I do the captcha equivalent of 2 Satoshi and only get 1 Satoshi.

There are no shortcuts, nor any free rides.

First off, you aren't going to be able to do anything with 1 satoshi.  You wouldn't be able to afford the mining fee to transfer it anywhere, which means that it has essentially been taken out of circulation.  As it stands, everything you can do with 1 satoshi you can currently do with 0 satoshi.  For amounts that small, you shouldn't bother.

Second, your time has value.  Regardless of your electricity costs, setting up a CPU/GPU to mine bitcoin will take time.  Furthermore, with so little hashing power, you aren't going to see a payout anytime soon...even while mining on a pool.  You are probably better off trying to use the faucet you mentioned.

As it stands, the least expensive (both time and money) and fastest way for you to obtain a usable amount of bitcoin is either to purchase some, or sell a product/service in exchange for some.

I know this is not what you are looking for, but I assure you that it is the truth.


Is it possible to buy bitcoins via an exchange directly into cold storage? I own a cold storage wallet. I want to buy bitcoins, directly into my offline wallet (in order to avoid extra transfer fees).

I understand i have to pay exchange fees. What I want to avoid is: buy bitcoins into wallet H (paying exchange fees), and then transferring to cold wallet C (paying transfer fees). I do not want or need wallet H (hot), so I want it out of the picture completely. I have not seen any exchange advertising bitcoin buying into cold storage, that is why I am asking

Are there any services supporting this kind of setup?

You can generate a wallet for cold storage offline easily. You can then ask the exchange to use a public address of that cold storage as the recipient for a transaction. You'd still pay the fee the exchange demands to process the transaction though.

Standard practice is that all trades in the exchange are just bookkeeping and are not published to the blockchain at all. Simplifying things a bit: The exchange uses a single wallet to receive all bitcoin transactions for all users. Each user is credited that much in their account. Trading moves some of the balance from one user to another. Once you withdraw, you withdraw from the shared wallet to an address of your choosing. In most exchanges, you can't trade directly into your own wallet.


Are privatekeys Case-sensitive? I want to print privatekey into block of steel, but I have only uppercase letters, so I wonder if privatekey is case sensitive?

A private key is a 256-bit number. You can represent it using only digits (so there is no need for lowercase letters). However, if you want to use the Wallet import format to represent the key, then you will need both upper and lower case letters (keys are encoded in Base58).


BIP-32 - how can parent extended public key exposed parent extended private key? The below is the snippet from bip-32. I do not understand under what circumstance would 'parent extended public key' be exposed? In the case of e-commerce a 'child extended public key' is derived from 'parent extended public key'. The e-commerce website only needs to know 'child extended public key' to derive public key/addresses. In such case, will knowing 'child extended public key' expose 'parent extended private key'?

"One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it)."

Example of code snippet in Javascript

function testXPub() {
 const mnemonic = 'ddddddddddddddddddddddddddddddddddddddddddddddd'
 const seed = bip39.mnemonicToSeed(mnemonic)
 const node = bip32.fromSeed(seed)
 const xpubNode = node.neutered()
 console.log("xpubNode :%o", xpubNode)
 console.log("xpubNode (string): %o", xpubNode.toBase58())

 const xpub_m_0_node = xpubNode.derive(0)
 console.log("xpub_m_0_node :%o", xpub_m_0_node)
 console.log("xpubNode (string): %o", xpub_m_0_node.toBase58())
 const xpub_m_0_0_node = xpubNode.derive(0).derive(0)
 console.log("xpub_m_0_0_node :%o", xpub_m_0_0_node)
 console.log("xpubNode (string): %o", xpub_m_0_0_node.toBase58())
}

So instead of sharing xpubNode, i would share xpub_m_0_0_node.

I am interested to understand as per bip32, why would anyone share the 'parent extended public key'?

The purpose of sharing the parent extended public key is so that child public keys (and thus addresses) can be derived from it without needing to know about a bunch of addresses individually. This is easier for separated setups where an online computer only has the public keys as the online computer does not need to be constantly refreshed with more addresses to watch for. It can generate the addresses itself.

  In such case, will knowing 'child extended public key' expose 'parent extended private key'?

No. Only knowing both the parent extended public key and a child private key derived with unhardened derivation exposes the parent private key.


Why are negative fees not allowed? Why does Bitcoin consensus require blocks to contain only non negative fee transactions? Also why does the coinbase have to be the first transaction in a block with this rule lifted?

Instead of having those rules, which need to be special cases in the software, I suppose one could just have this rule:

  The sum of all outputs in a block minus the sum of all input values in the block must not exceed the block reward.

This rule is already in place to check the block reward, so the other two rules seem useless. A miner which includes a transaction with a negative fee will have to pay for it by the one rule, so nothing bad can happen.

If Bitcoin was using just this one rule I could imagine interesting things could be done with CPFP.

One possible reason I could think of was spam protection, however nothing prevents me from creating a huge amount of spam transactions with 0 or 1 satoshi/B anyway.

Very interesting brain teaser. I agree that this could be interesting in combination with CPFP. The sender could defer the transaction fees to the recipient which would probably be an interesting proposition for some services in the Bitcoin space.

There are a few problems with negative fees from an operational perspective, though:

The sender defers prioritization to the recipient. However, if the sender needs to access the funds that are assigned to the change output of the transaction, he'll either have to CPFP the transaction himself after all, or doublespend the transaction to add more outputs.

In the first case, he ends up paying the fees himself, in the second case, he creates a scenario where multiple valid conflicting transactions float about unconfirmed, and since he doesn't know which one will confirm first, he'd better also broadcast all alternative complementary transactions.

I.e.

tx1: S --> R1 + C

tx2: S --> R1 + R2 + (C-R2)
tx1b: C --> R2 + (C-R2)

This would quickly increase the amount of transaction combinations that could be accepted on the network, create unnecessary network traffic, and would create a headache for fee estimation: At the same negative feerate, it would be much cheaper for R1 to just purchase tx1, while R2 would have to come up with the fees for tx2 (which is cheaper than tx1+tx1b).

In general, if there are multiple recipients to the transaction, the first to spend from the transaction has to pay for everyone to receive their money.

Another problem is that it may further incentivize out of band payments for transactions which at a larger scale could cause unpredictability in transaction confirmation times, and may skew other incentives in the network.


Bitcoin API with bech32 support Since a while, I have been using the insight-api to view bitcoin transactions. However, recently I have found out that bech32 addresses are not supported.

Now I try to fix this issue and I am open for any suggestions.

It there some other suitable api that also supports bech32-addresses? Or, also appreciated, is there some workaround available for the insight-api

It looks like bitcore replaced the insight-api


How can I run an Electrum console command from outside Electrum (in Linux)? I want to use my electrum wallet balance in my another python application.
How do I make a call to the getbalance() function?

You might find it easier to just query an electrum server directly. Stratum is a nice protocol in that it's easy to use in an ad-hoc fashion.

If you're using python3 this is almost certainly the easier solution, too.

def get_from_electrum(method, params=[]):
    params = [params] if type(params) is not list else params
    s = socket.create_connection(('ecdsa.net', 50001))
    s.send(json.dumps({"id": 0, "method": method, "params": params}).encode() + b'\n')
    return json.loads(s.recv(99999)[:-1].decode())

get_from_electrum('blockchain.address.get_balance', '1MaxKayeQg4YhFkzFz4x6NDeeNv1bwKKVA')

Result:

{
    "result": {
        "unconfirmed": 0,
        "confirmed": 237093847
    },
    "id": 0
}

Documentation: https://electrum.orain.org/wiki/Stratum_protocol_specification


Can I Replace An Old Wallet.dat File In Bitcoin Core Before It Fully Syncs? I have an older wallet.dat file I'm trying to re-open in the latest Bitcoin Core version (0.20.1). Once I replace the empty wallet.dat file with the older one:

Do I need to wait for the entire blockchain to sync before seeing the contents of the wallet?
(The point I'm at in downloading the blockchain is well past where the original wallet date was)

If I'm able to see the entire contents of the old wallet before the blockchain is finished syncing can it be done offline or do I need to keep Bitcoin Core online?

I assume you are cleanly shutting down bitcoin-core before you overwrite wallet.dat.  This is absolutely a requirement.  You can't replace an open wallet file while bitcoin core is running.
#1 - Yes, you need to complete the initial block download to see the contents.  Since you already download some blocks before the wallet born-on date, you will need to issue a rescan to look for wallet transactions before the block your currently downloading
#2 - You can always see the keys of the wallet regardless of how far the download has gotten, but you won't get the balance until the download is complete.  Once you have all the blocks you can do everything offline, but of course it won't see TXNs in blocks that you haven't grabbed since going offline.


multibit balances wrong, not correct for any individual address In my multibit wallet, it reports X bitcoins.  But no address in that wallet contains exactly X bitcoin, and the total reported amount should be greater than X.

The reason this is stranger than normal is because when additional bitcoin is sent to an address in that wallet, the X increases by the right amount, but it just conveniently forgets to accurately display an amount that is reflected in ANY single address in that wallet

Address 1 has W bitcoin in it, W is less than the reported X amount
Address 2 has Y bitcoin in it, Y is greater than the reported X amount
Address 3 has 0 bitcoin in it.

So X is some combination of Address 1 and Address 2's balance, but it is not either of them

The "3 reset" trick does NOTHING to fix this. And in some gamble that it does display my whole balance after a blockchain reset, it only displays it until a transaction is made, or the application is restarted. In which case my only resource seems to be to reset the blockchain over and over again, or consider MultiBit's HORRIBLE non-advise of moving everything to a new wallet in a different application by exposing the private keys.

Help?

due to this bug and other reported bugs seemingly related to improper accounting of change addresses escalating to LOST BITCOINS see someone else's post here: (http://www.reddit.com/r/Bitcoin/comments/22gt4r/major_mulitibit_bug_btc_gone_it_cost_me_all_of_my/)

I've switched to electrum, fortunately at the time (tons of blockchain resets), multibit was reporting my entire balance and was able to move it all to my electrum addresses.


Is the HashOfThingToSign (used in signature generation) the same for each input of a transaction or is it different for each input of a transaction? Does a transaction with 50 inputs have 50 different hashofthingtosign, one for each input, or does it just have one that is used for all the input scripts?

It is different for each input. Each input's hash preimage contains that input's previous output's scriptPubKey in that input's scriptSig. All other inputs have empty scriptSigs. This means that the preimage for each input is unique, and thus has a unique hash.


If a bitcoin wallet service provider terminates a users account, what happens to the funds? A friend of mine has/had a bitcoin wallet service provided by an online marketplace. Sounds like he had some kind of disagreement with the site administrators and they terminated his account. At that time, he still had some BTC in the wallet. Not a lot (about $50.00 USD or so), but still.

Is there any way to recover the funds, or are we all at the mercy of our wallet service providers in that respect?

Seeing as all transactions are recorded in the ledger, I figured perhaps there's some way to claim/prove/declare ownership. It seems pretty thin, but surely there's some kind of safeguard in place, otherwise wallet service providers could exploit that trust and just terminate all their customers accounts and take all their funds with impunity at any moment. Right?

This is why people say "Not your keys, not your bitcoin. Your keys, your bitcoin". The online marketplace owner owns the private key of the address that your friend used to fund his account. The owner of the marketplace can always say he lost the private key of your friends' account, but if he wants, he can prove ownership by signing a message with the private key (he has nothing to gain though).

Your friend should provide a new address to the owner of this marketplace and ask him to send the bitcoin that he had to that address, otherwise, yes, he is probably stealing.


Are ASICs Resistant to Malware Attacks? One of the arguments made in favor of relying on ASIC mining hardware to secure the Bitcoin blockchain is that commodity hardware is more prone to a 51% attack since an attacker could easily infect millions of computers through a malware attack and use the computer's resources to execute a 51% attack against the network.

It's very hard to.. hack into someone's SHA256d ASICs

Are ASICs really resistant to malware attacks? If so, why?

Resistance to malware really just comes down to the security practices of the hardware's operator.
Simply put, we might expect that the admin of a mining farm would be quite vigilant in terms of security, compared to your average person with a PC at home. Thus, we could expect that it is easier to infect and control the average PC, compared to a mining farm.


How is the network hash rate calculated? Miners work on finding blocks but don't sent anything until they find the block.

Considering that, how can sites like bitcoincharts.com display a graph of the network hash rate?

The hashrate can be calculated from the expected rate of finding a block (144 a day), the actual rate of finding a block and the current difficulty.

So let's calculate the average hash_rate for a single day:

expected_blocks = 144
difficulty = 11187257.461361 # this is on May 22nd 2013
blocks_found = 155 # Also May 22nd 2013
hash_rate = (blocks_found/expected_blocks*difficulty * 2**32 / 600)

The reason we use a day to average out the hash_rate is that taken block by block the variance would be really high and we would not get anything meaningful.

According to WolframAlpha this gives us an averagge hash_rate for the 22nd May 2013 of 86.19 THashes/s. Numbers of course may vary depending on how you chose your interval, which appears to be the reason numbers don't match with the ones on Blockchain.info


Hardware Wallet Security if Computer App (MEW, Ledger, Trezor) is compromised I have bought a Ledger and Trezor.

I don't want to use My Ether Wallet, it gets hacked! I just want to go from the exchange to the Trezor. But, I have about 15 ALT COINS and I'm reading and hearing I can't use the Trezor/Ledger for all of them?

Is there a better alternative? How are hardware wallets secured against MEW hacks?

But, I don't want to use MEW My Ether Wallet, it gets hacked!

The point of a hardware wallet is that even if the software or service you are using is compromised that your private keys are still safe. So even if MEW gets hacked, you can still use it and be sure that your private keys are still secure. The private keys never leave the Trezor or Ledger and in order to send any money anywhere, you need to confirm it on the device so your coins can't be stolen without you being aware of the transaction.


Implementation of the Variable length integer in C Anyone can give me a idea of how implement in C this concept of Variable length integer which encoded the numer of transactions in a block? based on what is described here, I think is something lime that:

if(value=?)
    uint8_t number_transactions = length;
else if(value=?)
    uint16_t number_transactions = 0xFD+length;
else if(value=?)
    uint32_t number_transactions = 0xFE_length;
else
    uint64_t number_transactions = 0xFF_length;

where number_transactions would be the value concatenated on the block. But how implement this? This code does the same described in the bitcoin wiki?

UPDATE

char* varint(unsigned long size) {
  char* number;
  if(size < 252) {
    number = malloc(1);
    number[0] = (uint8_t)size;
  } else if(size>=253 && size<65535) {
    number = malloc(3);
    number[0] = 0xfd;
    memcpy(&number[1], (uint16_t)&size, sizeof(uint16_t));
  } else if(size>=65536 && size<4294967295) {
    number = malloc(5);
    number[0] = 0xfe;
    memcpy(&number[1], (uint32_t)&size, sizeof(uint32_t));
  } else if(size>=4294967296) {
    number = malloc(9);
    number[0] = 0xff;
    memcpy(&number[1], (uint64_t)&size, sizeof(uint64_t));
  }
  return NULL;
}

message from compiler:

bitcoin_rpc.c: In function ‘varint’:
bitcoin_rpc.c:230:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     memcpy(&number[1], (uint16_t)&size, sizeof(uint16_t));
                        ^
bitcoin_rpc.c:230:24: warning: passing argument 2 of ‘memcpy’ makes pointer from integer without a cast [-Wint-conversion]
In file included from bitcoin_rpc.c:4:0:
/usr/include/string.h:42:14: note: expected ‘const void * restrict’ but argument is of type ‘short unsigned int’
 extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
              ^~~~~~
bitcoin_rpc.c:234:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     memcpy(&number[1], (uint32_t)&size, sizeof(uint32_t));
                        ^
bitcoin_rpc.c:234:24: warning: passing argument 2 of ‘memcpy’ makes pointer from integer without a cast [-Wint-conversion]
In file included from bitcoin_rpc.c:4:0:
/usr/include/string.h:42:14: note: expected ‘const void * restrict’ but argument is of type ‘unsigned int’
 extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
              ^~~~~~
bitcoin_rpc.c:238:24: warning: passing argument 2 of ‘memcpy’ makes pointer from integer without a cast [-Wint-conversion]
     memcpy(&number[1], (uint64_t)&size, sizeof(uint64_t));
                        ^
In file included from bitcoin_rpc.c:4:0:
/usr/include/string.h:42:14: note: expected ‘const void * restrict’ but argument is of type ‘long unsigned int’
 extern void *memcpy (void *__restrict __dest, const void *__restrict __src,

No. The compact size unsigned integers are not uints (except for the base one of one byte). They are a serialization, so it is actually just an array of bytes. You just compare the number you are serializing to the boundaries and determine from there what the prefix byte is. Bitcoin.org does a better job of describing this: https://bitcoin.org/en/developer-reference#compactsize-unsigned-integers. Note that you will need to understand hex numbers are and how they work in C.


Using vanitygen To generate addresses for different cryptocurrencies I know how to use vanitygen but how do you determine the number that will correspond to the -X parameter for a different cryptocurrency? For example it is -X 30 for Dogecoin.

I found some here.

LTC: 48
FTC: 14
NVC: 8
ANC: 23
PTC: 47
CNC: 28
DGC:30
NMC: 52
PPC:55
YAC: 77
BQC: 85
IXC: 138
DOGE: 30

Proper syntax for VanityGen is: (from this question)

Usage: vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...]
Generates a bitcoin receiving address matching <pattern>, and outputs the
address and associated private key.  The private key may be stored in a safe
location or imported into a bitcoin client to spend any balance received on
the address.
By default, <pattern> is interpreted as an exact prefix.

Options:
-v            Verbose output
-q            Quiet output
-r            Use regular expression match instead of prefix
              (Feasibility of expression is not checked)
-i            Case-insensitive prefix search
-k            Keep pattern and continue search after finding a match
-N            Generate namecoin address
-T            Generate bitcoin testnet address
-X <version>  Generate address with the given version
-t <threads>  Set number of worker threads (Default: number of CPUs)
-f <file>     File containing list of patterns, one per line
              (Use "-" as the file name for stdin)
-o <file>     Write pattern matches to <file>
-s <file>     Seed random number generator from <file>


Synchronize mempool between 3 nodes Three bitcore nodes (version of bitcoind is quite old - 0.12.1) are deployed to the servers on different cloud platforms.

All instances have the same bitcoin.conf files (except of rpcallowip, rpcuser and rpcpassword):

server=1
whitelist=127.0.0.1

txindex=1
addressindex=1
timestampindex=1
spentindex=1

zmqpubrawtx=tcp://127.0.0.1:28332
zmqpubhashblock=tcp://127.0.0.1:28332

rpcthreads=8
rpcworkqueue=32
rpcservertimeout=60
rpcallowip=127.0.0.1
rpcuser=...
rpcpassword=...
uacomment=bitcore

The problem is all of them have considerably different mempools:

first has 33689 txs in mempool
second has 58219 txs
third node has 39540 txs
blockchain.info has 63598 txs

I understand, that mempool is node-specific and there is no "Single Bitcoin Network Mempool". However I need synchronization at least between these three nodes (though it would be better to be as close to blockchain.info as possible).

If there is transaction, that exists in blokchain.info's mempool, but doesn't exist in all three nodes' mempools - it is ok. But as soon as this transaction get to one of these three nodes, it should appear on others as soon as possible.

I've tried using addnode option to force nodes connect to each other, but it didn't helped.

May be I am missing something, or at least there is a way to find the reason of so big differences in mempool ?

Aim of consistent mempool.

We have mobile client and application server, all looking into these nodes (some kind of load balancing). User can be logged into one account on different devices. When server sees transaction in mempool, it should update user's status.

When mempools differ it is possible, that:

User will see different transactions on different devices, which may mess him
User will see transaction, and server will miss it. In such situation user expects, that status will be updated, but server wouldn't do it

So it would be very nice, to have (almost) equal mempools.

So far.

I've tried:

addnode (to connect to specific nodes)
connect (to connect only to specific nodes), to give it a try, thanks to @whatever

This options were described here, on bitcoin.se, and (alongside with other possible options for bitcoind) in bitcoin wiki. But there is still problem with big difference in mempool's size.

You can force mempool synchronization by running a script which connects to the RPC ports, fetches transactions from one node's mempool, and sends it to the other nodes. Note that because this uses RPC, it will be fairly slow and will still result in some mempool desynchronization. You will probably want to run this script periodically. Here is an example in python using python-bitcoinrpc.

Note: I have not tested this

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

# rpc_user and rpc_password are set in the bitcoin.conf file
nodes = []
NODE1_URL = "10.10.10.1:8332"
NODE2_URL = "10.10.10.2:8332"
NODE3_URL = "10.10.10.3:8332"
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE1_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE2_URL)))
nodes.append(AuthServiceProxy("http://%s:%s@%s"%(rpc_user, rpc_password, NODE3_URL)))

for node in nodes:
    txs = node.getrawmempool()
    for tx in txs:
        rawtx = node.getrawtransaction(tx)
        for b_node in nodes:
            b_node.sendrawtransaction(rawtx)

What this does is it fetches a list of transaction ids in a node's mempool. Then it fetches each transaction and broadcasts them through the other nodes. It does this for each node. This, in theory, ensures that all of the nodes will have the same transactions in their mempool.


Does Bitcoin "confirmations" have nothing to do with fullnodes -- only miners? Roughly every 10 minutes, a new "block" is created. If Joe sends Sue a satoshi, it will be at least 9 minutes and 59 seconds until they get 1 confirmation (as I understand it). Then, subsequent blocks will increase the number of confirmations in perpetuity, with 6 blocks equating to roughly one hour.
But up until today, I always thought that "confirmations" were simply fullnodes (such as the non-pruned Bitcoin Core I'm running) "confirming" that the transaction took place.
Is this entirely false? If so, what is the point of my fullnode? Does it have any say/power whatsoever? It seems like the miners are the only ones who matter.

If Joe sends Sue a satoshi, it will be at least 9 minutes and 59 seconds until they get 1 confirmation (as I understand it).

This is not true. There is no fixed time interval between two blocks. You might see several blocks in a few minutes or no blocks for an hour. On average if looking at a bigger time frame, the block interval is ~10 minutes because of difficulty adjustments.

Then, subsequent blocks will increase the number of confirmations in perpetuity, with 6 blocks equating to roughly one hour.

Partially correct. Blocks mined after the first confirmation will increase a transaction's number of confirmations.

But up until today, I always thought that "confirmations" were simply fullnodes (such as the non-pruned Bitcoin Core I'm running) "confirming" that the transaction took place

Pruned nodes are also full nodes because they fully validate all blocks and transactions.

Full nodes do not add transactions to blocks. That is done by miners when they mine blocks.

If so, what is the point of my fullnode? Does it have any say/power whatsoever? It seems like the miners are the only ones who matter

Full nodes are used because you cannot trust others (verify all transactions yourself), privacy (not leak information about your transactions) and enforce consensus rules.

Miners are not the only ones who matter. Rather, if miners mine invalid blocks those get rejected by the full nodes.


Recovering wallet from MultibitHD backup file I was able to create a Multibit HD hash in the form of $multibit$232characters32characters*32characters... If Hashcat has uncovered a password for a mbhd.wallet.aes file, what's next? One thing I'm confused about is why did Multibit HD create a wallet file with the .aes ending when it's not even a AESCrypt file or maybe that's just to throw people off??
Anyway, it doesn't really matter as long as I have the wallet password, I guess. So, what are the next steps to take to see if the wallet has private keys or not? It is only 27 Kb so I'm assuming it's a dump of the private keys, if any or it could be corrupted. I don't know the process moving forward. I think I read that Multibit HD wallets are not safe and should be converted to something else, like Electrum or something... is that true? In addition, I do not have the 12 seed/secret words so Multibit HD doesn't allow you to enter a remembered password... it wants the seed words to recover the wallet.  What do you recommend and what's the correct process?  Should I try to get the seed words somehow or should I try to import the keys into Electrum or something else?
Also, how does one go about getting public keys or addresses or both from private keys? Google searches are not helping so much as the Multibit HD wallet information is old and I'm not sure it's reliable. Any help and/or direction would be greatly appreciated.

If Hashcat has uncovered a password for a mbhd.wallet.aes file, what's next?

I would either

use MultibitHD to recover the wallet or

manually decrypt the file and manually extract all the private keys

The second method probably requires a lot more knowledge of the internals of a Multibit wallet.

One thing I'm confused about is why did Multibit HD create a wallet file with the .aes ending when it's not even a AESCrypt file

From what I've read, Multibit HD wallet backups are encrypted using the AES algorithm where the AES encryption key is the "wallet words" (not the wallet password).
You don't say what caused you to think the file with the .aes filename extension was not AES encrypted?

it doesn't really matter as long as I have the wallet password, I guess.

If what I've read is right, the "wallet password" is of no help in using a wallet backup.
However maybe what Hashcat recovered was the twelve "wallet words"? If so you would be able to use those to recover the wallet.

I read that Multibit HD wallets are not safe and should be converted to something else

Multibit became defunct in 2017. I vaguely recall there was a Multibit classic that became defunct long ago. If I remember correctly it was superceded by Multibit HD. Anyway the multibit.org URL now redirects to an unrelated project which makes me suspect it will be hard or impossible to find any official documentation or support.
This is of course a good reason to never depend on any specific software to hold your backup of your private keys. Its probably safest to have a BIP-compliant recovery phrase or private keys in WIF format. Either of these would still be usable even if your wallet developers disappear and the software becomes unusable.

I do not have the 12 seed/secret words

Then it seems to me that hashcat has been of no use to you.

how does one go about getting public keys or addresses or both from private keys?

The easiest method is probably to use established wallet software
The algorithms are public. There are many libraries or bitcoin toolsets. Its a fairly broad subject. If I wanted to do it outside of an actual wallet I'd maybe look at PyWallet, btcutils and some of the other popular toolsets.


How do you configure windows to store the bitcoin blockchain data into another directory? I'm currently on windows and was wondering how do you make the qt client download the blockchain data to another directory? Since my main drive is a SSD hard drive, I don't have much space to spare. How would I configure this to make it download elsewhere?

Also would this apply to other qt clients like litecoin, ppcoin, etc?

Add '-datadir=path-to-directory' to the command used to start the client.  For example,

bitcoin-qt -datadir=D:\Bitcoin

to store the bitcoin files in the D:\Bitcoin directory.  Remember to enclose the directory path in double quotes if it contains spaces.  Also move the subdirectories as well as the main application directory to the new location.


Electrum receive tab I have requested some bitcoin from my friend and gave him the adress that is displayed in the "receive" tab in the electrum client.
After he sent them, I made a request for that amount in electrum and it is apparently "paid", as you may see below.
However, it does not show up in my history as an incoming payment. How do i get it to show up there?

Always when in doubt, check online block explorers (at least two as all of them are buggy to some extend and might freeze for some hours/days):

blockchain.info

insight.bitpay.com

blocktrail.com/BTC

etc.

...is your transaction there (you can search for your receiving address)? Is it confirmed? When it is not there at all you know it is not problem with your local wallet. If the tx is there you have probably problem with synchronization of your wallet - you can try to select different server to connect to (in Electrum's settings). You can also try running Electrum with different directory ('-D' command line parameter) to force it to download its metadata again and recreate your wallet from seed. You can also try to install Electrum on different machine & restore your wallet there. Maybe check your firewall, too.


bitcoin-qt not syncing on mac os 10.9 I have been using bitcoin-qt for about 7 months without any problems until a few days ago when I launched it and a message popped up saying I should upgrade. So I did, to bitcoin-qt (v 0.8.5). Now all I get is "Synchronizing with network" (Processed 0 of 250284). I have left it for hours and its not changing. I have checked my broadband speed and Im getting approx 7.5 meg. Any Ideas?

I have had the same issue. Instead of deleting blockchain data, I found that you can run the application with commandline arg to reindex and rescan:

/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -rescan -reindex


How to convert Litecoin difficulty of 6 to an expected time per block solved? The current difficulty for mining Litecoins is about 6. If I mine them at 25kh/s, how often should I expect to solve a block with a difficulty of 6?

I'd also appreciate an explanation (or formula) of how the calculation is done.

I don't know much about Litecoin, but if its difficulty works the same as in Bitcoin, then on average it takes approximately difficulty * 2^32 hashes to solve each block.

Since you're calculating 25000 hashes per second, it should take you around 6 * 2^32 / 25000 seconds to solve a block.  Or about 286 hours.

Does that sound about right?


bitcoin payment has big fees I am using the bitcoin-rpc and everytime i create an invoice from a PHP script, i create a new address. All is ok, i get the money after, i have a script that checks number of confirmations, then when i try to send my money back to another wallet i see 300 400 usd in fees
bitcoin-cli sendtoaddress "MY_BIG_WALLET" 0.1 "" "" true
When i look on blockchain i see that that everything were sent from every address that i have created
ADDRESS1 ... 0.06
ADDRESS2 ... 0.03
ADDRESS2 ... 0.078
... and so on
Fees are way to big ... How can i send everything from one big address and pay only 20$ usd fee [the default bitcoin fee, i see on some services, 5 usd]?
I believe i pay per vbyte ... but i want to send internally with low or no fees or something.
How big payment gateways like coingate/coinpayments/bitpay are doing this? They too create an adress for every transaction ...
Thank you.

Fees are way to big ... How can i send everything from one big address and pay only 20$ usd fee [the default bitcoin fee, i see on some services, 5 usd]?

To spend from a bigger amount instead of several small, you must have it. If you fragment your bitcoin holdings sending small amount (for testing purpose or any other reason) to your other addresses, then when you would send it further, you should bind several of them, taking up more space on the blockchain and consequently paying higher fee.
You choose the fee amount, maybe you overpay it ... anyway there is many factor that are involved in fee calculation so there is many ways to minimizing them, you can start here: https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees

I believe i pay per vbyte ... but i want to send internally with low or no fees or something.

There is not "send internally": either you can use Bitcoin testnet, that works with valueless testbitcoin you can have for free, or you use mainnet and your transactions pay as any other.

How big payment gateways like coingate/coinpayments/bitpay are doing this? They too create an address for every transaction ...

When payment gateways make payments, they aggregate them: they aggregate multiple inputs (customer deposits) with multiple output (customer withdrawals) in a single big transaction that pay a very big fee, but which is always lower than they would pay with many small transactions; moreover they collecting 5$ you say from any single customer that is paid with the big transaction (and some service also from customers who deposit).


Did Blockchain just ripped me of my bitcoin? I just completed my backup phrase security setup with blockchain after I was prompted to click finish. As soon as I click it the account confirmed a transaction I did not do transferring almost all my bitcoin to an unknown address. Could someone explain to me what happened and if I can get back my fund?

I would expect that Blockchain sets up your backup and security when you create an account. If you got prompted to put in your wallet information at a later time, that would have almost certainly been a phishing attack. I suspect that you were on a website that was not blockchain.info and the mock security setup provided the information to empty your account to your attacker.


Does solo mining still exist? Does solo mining still exists in Bitcoin or other alt-coins?

Is there a source of statistic about the share of pooled mining for the main alt-coins (similar to this for Bitcoin and this for Ethereum)?

Solo mining of Bitcoin would honestly require a serious setup, as well any setup would need continuous added infrastructure/hashpower as the difficulty of mining increases over time-- for any returns to be realistically expected within a "reasonable" timeframe. And that would be to find 1 block. Think 100s of TH minimum to even get lucky.

This is why even people who have setup large mining farms, say 50, or 100 miners, still rely on Pools where the combined hashpower of many miners together work towards solving the next block. This provides a more consistent return on investment and allows you to budget accordingly based on overall pool performance.

As far as Altcoins, new alts are relased all the time, solomining in a proof of work scheme becomes more difficult typically with higher network hashrates on that given coin. So its about getting in at the very very start. Usually difficulty jumps into the "pool now required" within minutes, or even faster.  The more miners hashing, the harder it will be to solve a block before someone else does, because the entire network is searching to solve the same hash. The difficulty will adjust automatically in order to maintain the specified block time (different for each coin). So it's a fight basically, between the miners, and the network hash rate adjusts to keep "in time" say, 1 block per 10 minutes, etc.

Yes, you can solo mine alts. But truthfully, unless you are going to run a serious setup; including configuring your own stratum proxy server, mining on a pool and paying the 1 or 2% fee is really the way to go.


Why is my Bitcoin wallet always out of sync? Why is my Bitcoin wallet always out of sync?

What can cause this?

New blocks are continuously being created (about once every 10 minutes).

So if you don't leave your client continuously connected, or when you're connecting for the first time, then when you do connect it will be out of sync and need to download and verify new blocks.

There are SPV (Simplified Payment Verification) clients (e.g., MultiBit and Bitcoin Wallet for Android), client-server clients (e.g., Electrum), and hosted (shared) EWallet web services (e.g., CoinBase, Paytunia, and others) -- each of which either lessen or eliminate the need to sync.

One method that brings the convenience of an EWallet but keeps the private keys local and not stored with the provider is Blockchain.info/wallet.

http://www.Blockchain.info/wallet

That might be a better client if keeping your client connected continuously is a problem for you.


Priorities in Bitcoin-qt Client On the bitcoin wiki its says:

  Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21). This threshold is written in the code as COIN * 144 / 250, suggesting that the threshold represents a one day old, 1 btc coin (144 is the expected number of blocks per day) and a transaction size of 250 bytes.

Meaning 1 BTC need 1 Day to become medium priority and will need no fees. On testnet I collected a few coins and checked the priority in bitcoin-qt client. It grows from low to low-medium to medium. Then it stops. While now on 570 confirmations it should be way higher than medium priority. Checking the bitcoin-qt sourceode there are more priorities deposited.

Did I missed something?

The relevant source is this:

if (AllowFree(dPriority)) // at least medium
{
    if      (AllowFree(dPriority / 1000000))  return tr("highest");
    else if (AllowFree(dPriority / 100000))   return tr("higher");
    else if (AllowFree(dPriority / 10000))    return tr("high");
    else if (AllowFree(dPriority / 1000))     return tr("medium-high");
    else                                      return tr("medium");
}

The label only changes to something higher than "medium" when the priority is at least 1000 times larger than the minimum. Your priority is large (I estimate 570/144 * 27 = 107 times the minimum), but it's not that large.


How would a bitcoin transaction fits into a double entry accounting A bitcoin transaction may have multiple input and multiple output. When we have a multiple input and multiple output scenario. Also, we might not be able to identify from which address the transaction fees original from.

SO how is that possible that we take bitcoin transaction from blockchain directly and fit into a traditional double entry accounting bookkeeping, taking transaction as below.

As a third party with only the public blockchain data, there is likely no way to accurately fit a random Bitcoin transaction into the double-entry accounting method. This is because a single Bitcoin transaction could represent the economic activity and payments of many different people, or of many different transactions. To say this differently: transaction inputs/outputs do not necessarily map 1:1 onto users/transactions. There are ways to create Bitcoin transactions such that any one transaction can represent a larger amount of economic activity (more people and/or payments involved), especially in consideration of higher level protocols such as the Lightning Network, federated sidechains, etc.

As an example, a coinjoin transaction is intentionally designed to make it nearly impossible to determine who the owner of the newly created UTXOs is. Even those that are party to the transaction itself would only have knowledge of their own involvement, the nature of the other inputs/outputs would be unknown to them. Here is an example of a coinjoin transaction.

Another example is a lightning network channel: in this case a couple of on-chain Bitcoin transactions could represent a potentially unlimited set of payments, but all of those payments will be happening off-chain, and so they cannot possibly be known just by looking at the Bitcoin blockchain. Here is an example of a lightning network transaction, there is no knowing how many payments were sent over this payment channel (unless you were party to the channel, of course). Here is a look at that channel, but from a lightning network explorer.

  SO how is that possible that we take bitcoin transaction from blockchain directly

You cannot, unless you have additional information about the transactions you are attempting to catalogue. Generally, this sort of info is only known to those that are party to the transaction, so you should be able to accurately account for your portion of involvement in any transactions you are involved in, but to do so for every transaction in the blockchain is ultimately impossible. Too much potential nuance and detail is not explicitly stored in the blockchain record (and for good reason, privacy and fungibility is important).

  Also, we might not be able to identify from which address the transaction fees original from.

There is no concept of 'which address fees originate from' inherent to the blockchain record, for more info see my answer here.


Mining and pending events I am trying to fully understand the block chain algorithm and in particular, the consensus.

My understanding is each miner has a pool of pending events -- events that have not yet been included in a block --.

What I can't get my head around is if I'm busy mining events A, B & C into a block. Then in the mean time, a new block arrives that already includes event A, and its chain represent the "most work chain". I should abandon my effort to mine and start mining again after this new block.

If that's the case, then when I restart mining, my pending events should only have B and C. That I understand.

But if the new block that now becomes the head of the block chain was not parented by my current main block, that means that I could duplicate event B & C (if the parent of the new block contained them).

So how do I need to manage pending events? Do I need to go back the new chain to make sure I don't make duplicates?

The way to do this is to validate each and every block before beginning work on the next block.  If you validate the block you will have verified each and every transaction included in the block.  This then gives you the knowledge you need to determine if particular transactions were included or not.  When they have been included in a block they are also removed from the mempool.  The process of first validating a block can be slow and is not always popular so many miners take shortcuts and mine using SPV (only the headers)  they are thus unaware of which transactions are included in each block while validation is occurring so to keep miner busy they will mine a block without including any transactions.


Public Key / Private Key Generation in a bash script (osx / ubuntu) I am creating a bash script (that I will happily share on github when done) that takes random public and private keys for bitcoin and then bottles them up in an AES encrypted container and then SSSS the key to unlock. (Aka, a really secure paper wallet to distribute but itself is worthless. ) For right now, the part that I have thus far "outsourced" was the public / private key generation using bitaddress.org to create the bulk addresses. I would like to pull that part into the bash script.

I have reviewed,
https://github.com/RobKohr/PHP-Bitcoin-Address-Creator/blob/master/lib/botg.sh
and found that 50% of the time the private key in fact does not "unlock" the public key. Further it only runs in Ubuntu not OSX. Further, my goal is to replicate the bulk function such that 50 or 1000 address could be created.

Does anyone have any scripts or suggested links / locations / examples to accomplish the creation of the key pairs?

Appreciated.

https://en.bitcoin.it/wiki/Vanitygen is a software which will generate BTC address keypairs at the command-line. Its main purpose is actually to generate "vanity" addresses which contain pretty custom strings, but if you run it as follows then you will get a continuous output of many random public-private pairs: ./vanitygen -k 1 (remove the -k to generate only a single pair rather than continuously generate). I have used these addresses in my testing (sending small amounts), and have always found the private-key to be successfully importable and usable in a wallet. I have personally run vanitygen on ubuntu precise and mac os x mt lion.


What restrictions will be placed on X509 certificates that are used in the payment protocol? I'm looking at BIP0070 and also this forum thread which is locked for some reason; so I'll post here.

When it comes to validating a certificate for the purpose of a Bitcoin payment, each certificate is "authoritative" for different things, such as SSL or S/MIME.  Some certificates also have something called a "Basic Constraints" set so an end entity isn't marked as a CA... thus confusing the CA validation framework Bitcoin is using.

Question

What are the Extended Certificate rights that are required for use with Bitcoin?  I would assume something with "server authentication" allows for "domain.com" payments, versus a valid email which is "user@domain.com" for SMIME.
Does the breadth of certificate validation types allow for unnecessary spoofing?
Is there going to be a visual distinction for different certificates (Those with "all purposes", are expired, for Server Auth, or email?)
Finally, can there be a requirement for DNSSec validation when communicating with a server?
Edit: Will certificates be validated in a "normal" manner such as validating the Basic Constraints?  (I'm pretty sure OpenSSL will do this for you in a platform consistent way)

What are the Extended Certificate rights that are required for use
  with Bitcoin? I would assume something with "server authentication"
  allows for "domain.com" payments, versus a valid email which is
  "user @ domain com" for SMIME.

answer: item - Each certificate is a DER [ITU.X690.1994] PKIX certificate value. The certificate containing the public key of the entity that digitally signed the PaymentRequest must be the first certificate. This MUST be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one, up to (but not including) a trusted root authority. The trusted root authority MAY be included. The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs.

Trusted root certificates may be obtained from the operating system; if validation is done on a device without an operating system, the Mozilla root store is recommended."

''I understood that digital signature is done locally, only after it is sent to the payment system and blockchain.''

font: [1];

  Does the breadth of certificate validation types allow for unnecessary
  spoofing?

answer: the RFC5280,  Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

already provides as digital signature has to be made, the support has to be by the software and or browser, according to RFC5280.
font: RFC5280  - version - May 2008

  Is there going to be a visual distinction for different certificates
  (Those with "all purposes", are expired, for Server Auth, or email?)
  answer:: this information does not appear in the BIP, it is only stated that the compatibility with x509 with the Root certificate will be verified. to then provide the signature and payment.

Finally, can there be a requirement for DNSSec validation when
communicating with a server?
answer:: I think there was some confusion on your part, the scope is only for ''This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.''
It does not leave the bitcoin p2p network.
font: [1];

  Will certificates be validated in a "normal" manner such as validating
  the Basic Constraints? (I'm pretty sure OpenSSL will do this for you
  in a platform consistent way):
  answer:: yes, but BTCCore does not use OPSSL as default:
  according: bitcoin-core.
  "On Bitcoin Core <0.12, you can start the bitcoind RPC server directly with SSL:"
  other font integral content BIP 0070


What do I need to consider, when I chose media to store a cold/offline wallet? I'd like to stash away at least part of my Bitcoins in an offline wallet which I will put in a bank deposit box.

Which media is recommended to use for that? Should I burn a CD/DVD or put it on an USB stick? Which one has the longest expiration date? Are there other alternatives?

I wouldn't recommend CD/DVD or USB sticks. CD/DVDs don't actually have that long of a lifespan. Googling around I found various different estimates and no exact number, but the consensus is that they will probably last less than 10 years. Finding an estimate for how long a usb drive will last is a little bit more hazy, but the numbers I saw for that were around aboutish 10 years as well.

There's a bigger reason why you shouldn't use CD/DVDs or a usb drive: accessibility. If you plan on locking this thing into a deposit box and forgetting about it for a while, there's a pretty decent chance that when you come back to get it you won't be able to read it. CD/DVD drives are already used less and less, and there's a pretty good chance that 10 years from now you won't be able to get your data because your computer can only read hyper-bluray disks and the USB 12.0 connector is shaped like an octagon instead of a rectangle.

I'd actually recommend printing it out. A paper wallet printed on good archival paper with archival ink can last a very, very long time. If you do this at home, it will probably cost you some money since printers that can use archival ink aren't especially cheap, but there are some online services that can do this for you too if you are willing to trust them. You could also probably find some archival paper and archival pens and actually write out your paper wallet for not too much money.

If you really, really want to go crazy, you could have your address keys machined into a piece of steel or aluminum. If you pick a material that doesn't rust easily, and store it out of the elements so it can't erode, your wallet will essentially last for ever.


can somone create guaranteed future transaction? How to create a transaction in Bitcoin that can be spend after a certain period (e.g. 1 month) such that:
1. It is guaranteed that the transaction will be valid after 1 month (the account has enough BTC in it).
2. The amount to be withdrawn is not locked for that period.

Lightning network will allow this to happen. However, the amount must be locked, which violates the second condition above..

You can create a transaction that has a lock time set. If a transaction has a lock time, it cannot be confirmed until after the lock time has passed. This mostly meets the first constraint.

However the inputs that it spends from could be spent by another transaction before the lock time of the original has passed, thus meeting the second constraint.

The caveat is that the lock timed transaction will only be valid if the output that it spends from is not spent yet. Bitcoin does not use accounts so there is no balance.


How does the transaction received from getdata relates to data from blockchain.info? Say my printed output format is for a tx object is:

<Tx version: (version)>
    ntx_ins:
        (TxIns prev_output_hash)
    tx_outs: (TxOut values), total:(sum of TxOut values)>

If I have this output:

<Tx version: 2
    ntx_ins:
<TxIn 8d203ebc847f5a0def5d50aa0f05da8701f6248b0db7ad313030bdbe3495c91e>,
<TxIn 4b995a79b3026d9dcceeb81cdf0b1599c8fbbd2a9d1466a3d97437a8b24ad02e>,
<TxIn 5da3a822d936733788d93a681be4ca8b3b6dc7d82c02713159ad59b75f9d0495>
    tx_outs: 0.00853117,0.00988388, total:0.01841505>

how does my data relate to the actual information that we can get from blockchain.info? Because when I checked the transaction hashes with blockchain.info I just don't see the connections, especially the output values.

Blockchain.info (and other block explorers) do additional processing of the transaction data in order to make it more user friendly to follow the path of coin movement through multiple transactions. Additionally, it seems that whatever you are using to print out the transaction details is not showing you all of the information.

In a transaction, each input specifies the output that it is spending by using the transaction id of the transaction containing that output, and the 0-based index of that output in the list of outputs. Blockchain.info in their own internal databases links these two transactions together thus allowing you to visit the page for the previous transaction.

They display addresses in inputs because they inspect the output that is being spent, determine the address it corresponds to, and shows that address as the input for a transaction. Bitcoin does not actually use addresses and you won't see addresses in the inputs of transactions.

For the outputs, it appears that whatever software you are using is not displaying the full output information. Outputs contain both an amount and an output script which is not being shown to you. This output script typically corresponds to an address, so blockchain.info will determine the corresponding address for an output script (if it has one) and display that. Because they have databases that index addresses and their transactions, they are able to both give you a list of transactions for a particular address as well as point you to the transaction that spends that output.


Will a paper wallet ever have format issues? I found a paper wallet in my drawer, created in 2011 and with quite a lot of money on it. The private key says 'wallet import format'. I'm pretty confident that I will have no problem with importing it into blockchain.info or bitcoin-qt right now.

But let's imagine you find a paper wallet in many years from now. Who can still read audio tapes today? Will there EVER be an import format change? Or is this 'wallet import format' so future proof that my (future) grandchild could claim the funds? If Bitcoin still exists, of course.

I guess the safest paper wallet would include code or instruction on the bottom how to convert ;-)

Short answer: no, there will probably never be format issues.

Paper wallets are in a better spot than audio tapes because they degrade less over time and there is no specialised hardware required to read them.  It's not that the method of how audio was stored on audio tapes has been lost to history, it's just that finding a machine which implements that method is getting more difficult.  Since the method of storage in a paper wallet is just text, it would take a pretty fantastic catastrophe to wipe that knowledge from the planet. You're right that it's important to note the specific format in which private keys have been stored.  But as long as you know that, you will always be able to recover the private keys, which are the fundamental method of bitcoin ownership.  Since the "import format" is just a method of recording these private keys, that makes your paper wallets as good as any digital one.

Long answer:  a fundamental break in the current methods of cryptography wouldn't cause any format issues, but it might cause other issues (assuming the Bitcoin network at large had enough warning to survive the problem itself.  If it happened faster than that the world would have much bigger problems than Bitcoin failure).  If this happened, it would be major news and any reasonably attentive person could ensure that your paper bitcoins are at least as safe as anyone else's.  Left ignored in this unlikely scenario, it might be possible for someone else to steal your bitcoins.  Otherwise they could be invalidated by a protocol upgrade if the network considered that preferable to mass theft (old digital wallets would be just as vulnerable as paper ones, leaving a lot of bitcoins up for grabs by motivated adversaries).

Cryptographic protocols are often eventually weakened.  But this tends to happen at least somewhat slowly (which is the main reason we use cryptography for anything important at all).  A weakening of the cryptographic protocols at the heart of the Bitcoin algorithm would have far-reaching consequences for the entire computing industry:  banks, governments, corporations, etc. would all be scrambling to respond.  You would hear about it.  As long as you followed the convention Bitcoiners eventually settled on for responding to the threat, your bitcoins would be fine.  Or the world would end.  One of those two.

Paper wallets are also vulnerable to burning in the event of nuclear holocaust or a large asteroid collision.

tl;dr: to be paranoia-level safe you would want to ensure that someone is at least generally keeping abreast of Bitcoin news.