How to transfer bitcoins from old wallet to new wallet? Have no wallet.dat info I've been researching and trying different things for few weeks now and I hope that you guys will be able to help me out.

I'm attempting to recover my bitcoins from years ago.. but I have no wallet.dat on my backup and was wondering what's the best way to transfer them to a new wallet I've created?

Blockchain does show that I do have some BTC but I have no idea how to get it showing on the Bitcoin Core.

Thanks in advance

If you were using the Bitcoin QT (aka Bitcoin Core) client, then the private keys you need are in the wallet.dat file.

If you can't get that file, and you don't have any other record of the private keys, I'm sorry to say your funds are lost.

If you had used the Electrum wallet instead, you could recover your keys using the 12 word "seed", if you had that.

There were other wallets in use too; if you think you used something else as a wallet, let us know.


Why did Bitcoin Core switch from wallet.dat, cold.dat, lukewarm.dat, etc., into "sub-dirs"? I've noticed that Bitcoin Core and its API now strongly prefers to make a separate sub-dir in your datadir for each wallet, such as "lukewarm", which then contains a wallet.dat, instead of just having "lukewarm.dat" in the data dir.
Why was this change made? I can't tell you how much scary work it would be for me to update my own system into this new method. I refer to my wallets by their .dat filename and that's their internal label that I use to keep track of everything in my database.
I know that Bitcoin Core also supports the old way (different-named .dat files in the data dir), but for how long? And why was this change made to begin with? It seems to create some kind of log files or something which seem to contain nothing of value. What's that about? Am I missing out by clinging to the old way? I don't understand why it wants to segment wallets into wallet.dat files in their own sub-dirs.

The original move to a directory per wallet file was motivated due to an issue with the way Berkeley DB behaved when multiple databases were opened in the same database environment, which are tied to directories containing the database. In particular, the issue is that BDB creates a database environment log which contains data from all of the databases open. This creates issues with backing up and portability as database logs need to be backed up as well.
With the transition away from BDB to SQLite, it is possible that we move back to the old way. However current discussions around that seem to indicate that that move is unlikely.l


Why do some transactions take minutes and others take hours? I sent some bitcoins to an address and then looked on blockexplorer and it was there in about 10 minutes, which is what one should expect.

I did another send to a previously unused address and it took hours for the network to acknowledge it.

I contacted the help desk at Mt Gox and they said this happens fairly often.  My question:  Is this a known phenomena and if so what causes it?

Four factors affect this:

1) The size of the transaction. Smaller transactions get a lower priority. Abnormally small transactions look like spam.

2) The transaction fee. Abnormally low transaction fees may mean the transaction isn't even relayed. Miners have an incentive to include transactions with higher fees.

3) Luck. Some miners don't include any transactions. Some don't include any transactions without fees, even if the fee would normally be zero. So it comes down to who mines the next block or blocks. Also, 10 minutes is just the average. You could create a transaction and then by sheer bad luck the next block isn't mined for 20 minutes.

4) Security. The client 'dribbles' out its own transactions rather than broadcasting them to try to conceal the origin.


LTC mining is better than BTC mining? I've got a notebook with these specifics:

CPU: AMD Phenom X3 II N830 3.14GHz (3-Core)
GPU: ATI Radeon HD 5650 1GB

Mining 1 LTC is faster than mining 1 BTC? How I estimate the times for BTC and LTC?
Overall, I get more money with LTC mining or with BTC mining?

Nowadays, there are custom miners for Bitcoin. These use customised hardware (ASICs) and thus GPU mining is not profitable. However, this custom hardware does not exist for Litecoin and most other altcoins (based on scrypt). Thus, you might still be able to make money GPU mining Litecoin this way.

Unless you have customised hardware, forget about Bitcoin mining.

The other contributors are correct though - doing this on a laptop is probably not a good idea anyway, but you'll still make more doing Litecoin than Bitcoin.


How much does a bit coin cost? The reason I ask is because I just received an e-mail from someone who claims to have commandeered my cell phone camera and also my address book.  They said they would overlay my picture while watching
porn if I do not send them 869 usd worth of bit coins, or the will send my customized video to everyone in my address book.  The email header didn’t have any IP addresses or a MAC address.  The email address itself would not resolve to a valid domain. If anyone can help me find the owner of this bit coin address I would really appreciate it.
BTC address: 1Lq8TnU33SMFUXcyGYmwkfriaBAfEoX5Co
Thank you very much.
David

You've asked about five different questions here.

This is a standard scam and there is no reason to think they actually have anything.
There is no way to trace the owner of a Bitcoin address. That's why these scammers ask for payment in Bitcoin.
The cost of one bitcoin varies continuously, just like stock prices or currency exchange rates, but you can easily find the current exchange rate by Googling for something like "current bitcoin price".


If hardware wallet provider disappears, can I still manage my coins? I don't fully understand how hardware wallets work, there are two major brands, I will not name them.
I see they give you a seed and you can restore from that seed, but...

I understand these wallets only work with provider's mobile app, online interface or their computer software, correct ?
All transactions go trough their online service one way or another, correct ?
What will happen if their service simply goes offline ? Mobile app unavailable, etc ?
Am I able to see/export my private keys/coins so they could be use/spent by other means even IF the application or online service is unavailable and I only have my hardware wallet ?
Considering all the above concerns, doesn't that make the hardware wallet equally secure as a mobile app wallet ?

Thanks.

I understand these wallets only work with provider's mobile app, online interface or their computer software, correct ?

No. Some of the most popular hardware wallets are supported by third party software. For example, Trezors and Ledgers can be used with Electrum who have implemented support for these devices directly. Other wallet software like Wasabi Wallet and BTCPayServer support these devices through the Hardware Wallet Interface project which is also a third party project.
Other hardware wallets like the Coldcard don't have a vendor provided app at all and require you to use these third party software too.

All transactions go trough their online service one way or another, correct ?

Only if you use the vendor provided app. If you use a third party software, transactions will be broadcast in the manner which that software usually broadcasts transactions.

What will happen if their service simply goes offline ? Mobile app unavailable, etc ?

You will be required to use a third party software. The device itself will still function, but the vendor provided wallet will no longer be available. This does mean that there will not be any future firmware updates, but existing firmware on the device will function without the vendor having any online service.
In fact, most hardware wallets have open source firmware (even those with closed source chips like Ledger still provide a binary blob in their open source stuff) so others can make their own firmware even if the company stops supporting the hardware.

Am I able to see/export my private keys/coins so they could be use/spent by other means even IF the application or online service is unavailable and I only have my hardware wallet ?

Yes. When you setup the hardware wallet, it should have prompted you to write down a seed. This seed is usually a BIP 39 seed. This seed is used to generate all of your private keys. You can import this seed into any wallet that supports BIP 39 and be able to access your coins without the hardware wallet. However if you lose this seed, there is nothing you can do as private keys cannot be exported from a device (besides a few attacks and vulnerabilities where you can, but generally you aren't supposed to be able to do that).

Considering all the above concerns, doesn't that make the hardware wallet equally secure as a mobile app wallet ?

No, hardware wallets are more secure than a mobile app wallet. Hardware wallets don't rely on the vendor being online and still in business. Hardware wallets also aren't connected to the internet, they are intentionally a separate device so that any malware (mobile devices can get malware too) cannot retrieve the private keys. Even if a hardware wallet required the use of the vendor software, I would still consider it safer than a mobile wallet, although I would recommend that you choose a different hardware wallet to buy.


Is there any later version of Bitcoin address generation, than 1? I'm looking for the technical details regarding the format and generation of Bitcoin addresses. I've found this article, “Technical background of version 1 Bitcoin addresses”, on the Bitcoin wiki, but as the title says, it's version 1. It seems to be not talking about the version prefix used in generation of Bitcoin addresses.

Is there any later version of it, the method of the generation, such as version 2 Bitcoin addresses?

Yes, there are P2SH addresses, specified in BIP13. They were introduced in 2012 together with the P2SH consensus rule change. They use Base58 version number 5, and are mostly used for multisig constructions (where multiple parties/devices need to sign off on a transaction).

Recently Bech32 addresses were proposed in BIP173, to enable sending to native SegWit addresses. These addresses are easier to read/write, more compact in QR codes, and have better error detection properties. Native SegWit outputs are cheaper to spend and offer a higher security level (disclaimer: I authored BIP173).


Why GPU (cgminer) scrypt mining generates so many false-positive nonces? I understand that GPU might have less accurate results of real numbers because speed/performance is the target. But I don't understand why it also occurred in integer numbers.

Taking mining algorithm, scrypt hashing, for example, there are almost integer operations in SHA-256 or PBKDF, such as unsigned integer rotate, shift, add, xor, and bit-select operators. However, it does generate so many false-positive nonces. Everyone can invoke cgminer with arguments -T -D --verbose to see the detail logs. However, cgminer will verify the result via CPU routine again before sending it to mining pool because too many invalid share cgminer will be banned from the pool. Not everyone knows their GPU generates so many false-positive shares because the default log message does not show this.

So, I don't understand that. Is the problem in GPU or in the scrypt OpenCL code?

It's likely your intensity is too high. Usually higher intensity or other settings may look good with higher hashing power, but in truth results in a lot of false positives.

Playing around with the settings till you get the sweet spot is the best practice.


In Zcash, what statements do zkSNARKs prove? Zcash uses zkSNARKs to hide transaction details. My understanding is that the verifier is anyone that maintains the blockchain. My questions are:

If I decide to send x amount of Zcash to another user, what is the statement that zkSNARKs will hide?
In particular, is the transaction graph still public?

My understanding is that the verifier is anyone that maintains the blockchain.

All nodes that fully-validate transactions will be acting as zk-SNARK verifiers.

  In particular, is the transaction graph still public?

The transaction graph for shielded transactions is as private as it is feasible to be.

When a note is created, a commitment cm to the note is made public (effectively a hash of the note). When the note is spent, its nullifier nf is derived (effectively another hash) and made public. To the person spending the note, the local transaction graph looks like this:

(... -> tx1 -> cm)[<--- note --->](nf -> tx2 -> ...)

But to all other nodes on the network, all they see is:

(... -> tx1 -> cm)                (nf -> tx2 -> ...)

That is, they see when some note was created, and when some note was spent, but without knowing the private information (and assuming they can't find pre-images for the hash functions), they can't directly link the two events. They can exclude certain combinations of transactions, however:

A note cannot be spent before it was created, so when a nullifier is published, everyone knows that it corresponds to some commitment that was published previously, but not to any commitment that was published later.
Some nullifiers and commitments can be reasonably excluded based on other revealed information, e.g. if an exchange's records get leaked, or if they are in transactions that also involve transparent inputs and outputs. In particular, if you send funds from a t-address to a z-address and then on to another t-address, you get basically no privacy. See my previous answer about this for more information.

  If I decide to send x amount of Zcash to another user, what is the statement that zkSNARKs will hide?

The specific statement (for the Sprout circuit) being proved with the zk-SNARK (and therefore hidden) is given in section 4.9.1 of the Zcash protocol spec. Summarising its parts here:

Nullifier integrity: the published nullifiers correctly correspond to the input notes being spent.
Note commitment integrity: the published commitments correctly correspond to the output notes being created.
Merkle path validity: there is a valid path from the commitments of the input notes to the commitment Merkle tree anchor rt.

This enforces that the notes being spent were previously created.

Balance: The sum of the input note values is equal to the sum of the output note values (plus any funds entering or leaving the transparent pool, e.g. fees).
Spend authority: the provided spending key for each input note correctly corresponds to the public key the note was created for.
And a couple of other correctness requirements.

This is the majority of the consensus rules that get applied to transparent transactions. The only one missing is the double-spend rule, which is still checked outside the circuit (by checking that a nullifier has never been seen before).


Find recipient of a bitcoin transaction? Is there a way I can identify the recipient of a Bitcoin based on the transaction information? I have transferred Bitcoins a few years ago somewhere (possibly to Evolution marketplace, which was a scam) but I don't remember for sure where it went.

Since the blockchain doesn't store user's IPs or any useful person tracking information, it's hard to track down the recipient of a transaction.

But I read on few forums how Bitcoinstore owner tracked down a scammer to get the fraudulent refunded bitcoins back. You may come across a solution by studying this type of stories.

The details of the track down can be found Here


Does running a pruned node support the syncing of other nodes in the network? I decided to prune my Bitcoin core node to 25 GB. With the blocks that the node has in its data
directory (the ones that were not deleted), does such a node support the syncing of other nodes in the network? Moreover, let us imagine a new node that has just joined the network, let's say that has managed to download the first 10GB of data with his pruning set to 25GB. In such an early state, before pruning kicked in, does such a node serve the subset of the blocks that it has to the network?
Let the scope of this question be limited to the issue of syncing the blockchain data. I'm well aware of the advantages of using a pruned node as a wallet when compared to custodial services. There is already a question somewhat relevant to the matter and the answer to it suggests that as of May 2017, there is no way for pruned nodes to serve the subset of old blocks that they have. Is it still the case? Moreover, the answer to it does not refer to the second matter of serving a subset of blocks by a pruned node in which the pruning hasn't yet started.
Although I came across some resources and opinions on pruning, none of them elucidated the matter of syncing to me.

does such a node support the syncing of other nodes in the network?

Nodes that are pruned unset the NODE_NETWORK flag, which means that they don't advertise themselves as a potential source for block synchronization. Nodes won't consider peers without this flag as a potential source for downloading blocks.

In such an early state, before pruning kicked in, does such a node serve the subset of the blocks that it has to the network?

The same flag is not set here either. During sync most nodes are typically at 100% utilization and tend to behave very sluggishly, so they wouldn't be a particularly good source for anybody else.


How finding a working nonce says anyting about the validity of an initial transaction I am by no means an expert, nor a cryptographer, but I would be interested in knowning a little bit more than what happens at the end of the following chain of events.

What happens at the end of the following chain of events of course is related to what happens first, so please correct me if there are mistakes or incomplete parts in what follows!

Suppose we are in the situation where Alice (A) wants to transfer one Bitcoin to Bob (B).

A's private key has a corresponding public key. The private key is
used for the signature. This, together with hashed information
relative to the previous chain block, the timestamp and other
elements, constitutes the transaction.
The transaction is broadcasted to the network, where it waits until
    it's validated by the miners (together with other transactions).
In extreme synthesis, what miners do is to try to find a nonce that, added to the transaction data they receive and after being double-hashed, is satisfying a certain difficulty condition (set so that on average a new block is added, say, each 10 minutes).
Once a miner finds a working nonce, she sends it to the network so that it can be (easily) checked.
    In practice, since it takes time and effort to find that working
    nonce, this constitutes the proof of work.

What I find hard to understand is: how finding a random number such as a nonce can be proof that the transaction was effectively of one Bitcoin and from A to B?

And how can the nonce be the solution of the problem if no one but A knows about her private key?

In other words, I understand that it's extremely hard to find a working nonce, so that finding a compatible one is effectively proof that a lot of time and energies were spent to find it.
I don't understand how the solution to the mathematical problem of finding the nonce relates to the fact that the initial A to B transaction is valid (as opposed to be a wrong or "dishonest" one).

Finding the nonce and computing Proof of Work is unrelated to transaction validation. Locking blocks together in a chain of expensive Proof of Work ensures that is expensive to replace the current ledger/ blockchain with an alternative.

Further, transactions do not contain information about blocks or Proof of Work. Validation of transactions is achieved through the use of Elliptic Curve cryptography. Specifically, an Elliptic Curve Digital Signature Algorithm (ECDSA) over the curve secp256k1.

The mathematics of ECDSA ensure that only those who know the private key can generate valid signatures. However, any one can use the public key to verify that a signature was produced by somebody who has knowledge of the private key.

Lastly, to ensure that unspent transaction outputs (UTXOs) are not double spent, the Bitcoin protocol dictates that a block is invalid if it includes a transaction which references a specific UTXO as an input which has previously been referenced in a transaction input before.


Can a miner only receive a reward by finishing the latest block? Let's say there are 1,000 miners out there.

Every time a new block is added to the chain, all miners receive the updated blockchain instantly.

Do all miners immediately drop work on mining the current block & begin work on adding a new block?
If one miner has a machine that guarantees he is the fastest to complete a block, will he always receive 100% of the rewards in the network?

Relevant questions:

Can someone with 51% computing power earn more than he deserves?

Do all miners immediately drop work on mining the current block &
  begin work on adding a new block?

When someone mines the block on height N (the current head) and a miner receives that information he stops working on that height and moves to next height N+1 (on top of the block he just received). Although it can happen, because of network delay that miner receives some other block on height N before the block mentioned before. This will cause the fork in the blockchain, but again miner stopped mining on current height and go  mine on top of the block he received first.

  If one miner has a machine that guarantees he is the fastest to
  complete a block, will he always receive 100% of the rewards in the
  network?

The miner will (on average) mine percentage of blocks proportionally to his processing power comparing to power of all miners' power combined (=miners_power/total_mining_power_of_all_miners). The principle is same as in regular lottery: your chances of winning are proportional to the number of tickets you buy, if you have largest number of tickets, other players also can win, but your chances are biggest.


A theoretical low cost attack scenario in PoW currencies The scenario was designed by user:croraf and me in discussing a question of mine yesterday. To make it more clear, I want to present it here again in a stricter design.

To do it in a clear way, first four assumptions:

Transactions are accepted when N blocks confirm them.
We can make contact to the majority of the miners, they are egoistic and barely invested in the PoW currency.
An attack with the majority of mining power is possible. To make it more clear: We assume that rewriting blockchain history with undoing many transactions is so surprising, that we can get our benefits from the attack before the currency goes down.
There is an alt coin, resistant against our following attack scenario, without value correlation to PoW currencies. Mining hardware allows to mine the alt coin as well as the PoW currency.

Now the attack scenario.

We do a transaction with a higher value than mining benefits from N blocks. We wait until N blocks confirm our transaction, so the transaction is accepted by assumption 1. Than we bribe the majority of miners to create a fork to make our transaction undone. The bribe must be only a little bit more than the mining benefits on the "real" chain because they are egoistic and are not interested in keep the currency alive by assumption 2. Only paying the bribe the cost of the attack is very low relative to the promised win! The miners and we get our benefits from the attack before the currency is down by assumption 3. Then the PoW currency maybe goes down, but the bribed miners can go to mine the alt coin without any loss, what is possible by assumation 4.

Where is the fault, in the attack scenario or in the assumptions?

I think the attack scenario is correct and the suggested faults in the assumptions from the discussion yesterday can't convince my.

The most important critics I already know:

Assumption 1: We should only trust transactions with values comparable with mining costs, but this makes the currency inefficient, which was showed here.

Assumption 3: If you don't trust this assumption, so you deny usual attack scenario of PoW currency. If you do so, why shouldn't we do PoW with a very low difficulty and a very small mining power then?

EDIT: I think we can skip assumption 3 by doing the attack with a short position which means we do the high value transaction in the beginning with cryptos we have lended. I seems clear that the currency goes down after such a big attack and so we even profit from the short.

Where is the fault, in the attack scenario or in the assumptions?

The fault lies that you've discounted the opportunity cost it takes for an adversary or a conglomerate of miners to subvert the chain by forking off from some prior block. The key here is that there is inherent cost to forking the blockchain at some arbitrary height and re-creating the blocks. The cost can be formularised as block subsidy + total transaction fees in the number of blocks an adversary wishes to re-produce.

Firstly, honest miners will not be party to this, because they'd have to forgo their prior earnings and do double the work to re-earn the difference in your promised bribe transactions fees, so the conflict transaction you intend to bribe the miner with must be so great that it has to be double (at least) block subsidy + total transaction fees * N. Where N is the total number of blocks you want to re-organise. More importantly, what is it that the attacker seeks to achieve by donating away such a large sum worth of bribes (is it actually incentive-compatible to do so)?

Secondly, Assumption 3. simply does not make much sense as it lacks incentive compatibility. As you have shown, sure a miner can perform a naked short on an exchange before colluding to perform your described attack, there is risk to undertaking such a trade as an exchange out of popular interest can renege or withhold payments to a colluding miner that undertakes such a transaction. Simply put, it is more incentive-compatible for miners to mine transactions in an honest manner.


Would bitcoin core work on a big endian system? Or even a system where C++'s `int` is not 32-bit? Looking at the source code of bitcoin core, the serialization part, I see that there's no serialization abstraction layer that accounts for a possible different endianness or different binary layouts on different machines.

This is not only for disk serialization, but also for network serialization.
If bitcoin core was used on a big-endian machine, or a machine with int size not equal to 32-bit, it'll fail to connect to the network because all sizes will be incorrectly interpreted and values will be different.

Am I missing something or did I arrive at the correct conclusion?

It should work on big-endian systems. The serialization code for integers will byteswap on such systems. This was certainly tested at some point, but I'm not sure how recently someone has.

I don't think it will work on systems where int is different than 32-bit.


Can I export a xpub/zpub/ypub key in bitcoin core? I'd like to add a master public key (any of xpub/zpub/ypub https://support.samourai.io/article/49-xpub-s-ypub-s-zpub-s) for tracking purposes to Sentinel watch-only wallet https://samouraiwallet.com/sentinel.html but I cannot find an option to do this in Bitcoin core (v0.16.1).

Can anyone suggest how this can be achieved?

You cannot. Bitcoin Core does not allow you to import master keys nor can you export extended public keys. BItcoin Core does not use extended public keys since it uses hardened derivation which does not use extended public keys.


How many transactions have been included into the blockchain? This website shows the number of bitcoin transactions per day, but I want to know how many there are total. How can I do this?

As of block 210000, the total number of transactions in the chain is 9344662.

Version 0.8 of the reference client keeps track of this number, and reports it for every connected block in debug.log. I just copied the number from the debug.log of a node running pre-release code.


Stuck duplicate transaction in BitcoinQT I received two payments with the following transaction:

https://blockchain.info/tx/12e487de6fd8d920446cd8663dc11977d185ceaa25b7c6f36921fb76e58875f0

On this transaction

1HT1vrdy2fegnVKaTE1rqsFzfPVDpiWYjf output receives 0.1341765 BTC and 19tj6SNnJqZqmDvMuhrjwPudX8qVcT392a output receives 0.27240743.

I have this transaction in my BitcoinQT client. It shows confirmed and everything is fine. The problem is that I have another transaction which has the same inputs and outputs with the above but a different TxID.

It has been stuck in my wallet unconfirmed for two weeks. BC.info does not show this transaction. Neither does any other online service. Below are the full details.

I have around 10 other transaction in my wallet like this. What is this?￼ Why is this happening?

gettransaction 98ea1e0d4169af104fe36535a4615ab82086750323ce4e539b7d9c82707955f6
{
"amount" : 0.40658393,
"confirmations" : 0,
"txid" : "98ea1e0d4169af104fe36535a4615ab82086750323ce4e539b7d9c82707955f6",
"time" : 1392119952,
"timereceived" : 1392119952,
"details" : [
{
"account" : "520c7bb149ede83218f46c96",
"address" : "1HT1vrdy2fegnVKaTE1rqsFzfPVDpiWYjf",
"category" : "receive",
"amount" : 0.13417650
},
{
"account" : "520c7bb149ede83218f46c96",
"address" : "19tj6SNnJqZqmDvMuhrjwPudX8qVcT392a",
"category" : "receive",
"amount" : 0.27240743
}
]
}

gettransaction 12e487de6fd8d920446cd8663dc11977d185ceaa25b7c6f36921fb76e58875f0
{
"amount" : 0.40658393,
"confirmations" : 2490,
"blockhash" : "00000000000000007465867d49096a642c424ae015691c0b0f6280c3bc6de401",
"blockindex" : 78,
"blocktime" : 1392120874,
"txid" : "12e487de6fd8d920446cd8663dc11977d185ceaa25b7c6f36921fb76e58875f0",
"time" : 1392120874,
"timereceived" : 1392120896,
"details" : [
{
"account" : "520c7bb149ede83218f46c96",
"address" : "1HT1vrdy2fegnVKaTE1rqsFzfPVDpiWYjf",
"category" : "receive",
"amount" : 0.13417650
},
{
"account" : "520c7bb149ede83218f46c96",
"address" : "19tj6SNnJqZqmDvMuhrjwPudX8qVcT392a",
"category" : "receive",
"amount" : 0.27240743
}
]
}

Bitcoin Core (bitcoind and Bitcoin-Qt's new name) v0.9 will deal much better with these conflicting transactions within one wallet.

It will keep showing both, but the non-confirming one will be marked "conflicted" with -1 confirmations, will not be rebroadcasted, and won't be considered to have spendable outputs.


What is learned from listening for inventory messages? I am reading the paper Deanonymisation of clients in Bitcoin P2P network [PDF] and have some questions about the fourth step in 'chapter 5: Deanonymization'

I don't understand the emphasized part:

  Step 4) Mapping transactions to entry nodes:
  The attacker listens for
  INVENTORY messages with transaction hashes received over all
  the connections that she established and for each transaction
  T she collects RT — the first q addresses of Bitcoin servers
  that forwarded the INVENTORY message.

What information is learned from these inventory messages? I thought it contains only the transaction hash.

Thank you for your answer. I still have some problems to understand the paper.

Step: I'm sending the GETDADDR-Message to all my Entry-Nodes and they answer with the ADDR-Message which contains the IP addresses of their known Nodes. Now I have my set S with IP addresses.
Step: I'm choosing the subset E of S which contains the ip addresses I want to identify.
Step: Now I want to map new connecting clients to the bitcoin network with their entry-nodes (entry-nodes are elements of E).
Step: This runs parallel to Step 1-3. In this step I'm listening to all INVENTORY-Messages. So you said the INVENTORY-Message contains the transaction hash and an enum. How will be one INVENTORY-Message generated? Will this message generated for every transaction and distributed by broadcast to every known node in the bitcoin network? Who creates this INVENTORY-Message?

Did I correctly understand the first three steps?

The inventory message only contains the transaction hashes or block hashes and an enum that specifies which type a given hash is. In the paper, when they talk about addresses, they mean IP addresses. What they are describing here is that the attacker takes note of the first couple of IP addresses (in this case, 10) that sent out inventory messages for a transaction hash.

Edit to answer your follow ups:

  Step: This runs parallel to Step 1-3. In this step I'm listening to all INVENTORY-Messages. So you said the INVENTORY-Message contains the transaction hash and an enum. How will be one  INVENTORY-Message generated? Will this message generated for every transaction and distributed by broadcast to every known node in the bitcoin network? Who creates this INVENTORY-Message?

The inventory message is just a message sent to a nodes peers. It is not forwarded to other nodes as it is not a message like transaction and block messages.

If you (as a node) receive an inventory message from me (as a node), that means that I am announcing to you that I have a transaction or a block which you might be interested in. If you want that transaction or block, you will respond with a a getdata message and I will respond to that with the transaction or block itself.

  Did I correctly understand the first three steps?

Yes, I think you did.


Why did the lightning network implement a gossip protocol? As pointed out by many lightning developers in the past (e.g. Rusty's 1 million channel challenge) the gossip protocol is quite noisy and a part of the BOLTs causing many engineering challenges.

Today, I learned that Ethereum's Raiden network does not have a gossip protocol. Since all channels in Raiden are smart contracts that live in the Ethereum blockchain, Raiden nodes are supposed to learn about the network topology by looking at the Ethereum blockchain.

I believe funding transactions could have been designed to store information about Lightning nodes. Why was that not done?

Reasons I see:

With our design we can have private channels
blockspace is valuable, so we did not want to store more info on chain than necessary
we needed a transport and communication protocol between nodes anyway, so why not add the Gossip protocol?

My feeling is that there must have been other reasons for that design decision. So what am I missing?

The main idea of Lightening Network is to make the Transactions as fast as possible and to solve blockchain Network scalability issues. Whereas the main essence of the Gossip protocol is that each participant randomly selects a peer and exchanges state. As it can be seen that  Gossip approach is converging in O(logN) gossip rounds where N is the number of participants. Whereas communication on off-chain Network is only O(1) hence reducing the space on the blockchain. Applying Gossip protocol to the lightening Network on defeats the property of 'Lightening' and makes the network massively less scalable. Hope you like the answer.


how to transfer coin using bitcoin rest API I've been googling for quite some time now, but I was unable to locate any complete example, with the request & the POST/GET parameters to the Bitcoin JSON-RPC.

How to use the JSON-RPC ? How to use it to make a transaction ?

The list of json RPC commands is located on the wiki: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

There is a list of json-rpc wrapper libraries on the blockchain wallet API page: https://blockchain.info/api/json_rpc_api

Pick a wrapper library for the environment you develop in and dive in.

To create a transaction, you're going to likely use "sendfrom" or "sendtoaddress".


Have I backed up my wallet sufficiently? I'm trying to make sure I'm backing up my bitcoin wallet sufficiently. I only have about $60.00 worth, so I'm not looking for super secure encryption or anything. I just want to make sure I can restore my wallet if my computer crashes.

Anyway, I'm using MutliBit. I went to Tools -> Export Private Key.  I then selected a location on my network drive, added a password, and hit the export button.

If something happens to my computer, I could just redownload the multibit client and install it on another computer, and then use the Restore Private Key function and direct it to the file on my network drive to restore my wallet.  Is that correct?

I suggest to use paper wallet with encrypted private key, so called BIP-38.

Fundamentally, the only way to loose the access to those funds is by physically destroying the paper/forgetting the passphrase. Note that, keeping paper safe is much easier than keeping safe wallet.dat in computer that is connected to internet.

Following guide takes 2 minutes and is 100% secure if enhanced by using computer that has never been and never will be online - can be formatted before and after creation of cold storage.

Go to: bitaddress.org
Download .zip file on the buttom of page or from GitHub repository
Extract .zip and run file bitaddress.org.html
Move your mouse to generate random entropy for generating new bitcoin address
Navigate to Paper wallet tab
Fill 1 address to generate and check BIP-38 Encrypt checkbox
Enter the passphrase (only you would know and need to remember)
Click generate, and print this on the paper
Scan the Load & verify Public key and transfer there funds from MultiBit
You do not even need to keep the paper safe now, since person who would scan the Spend QR need to know the passphrase which is only in your brain


Set fee in Electrum RPC I'd like to pay people using the following command:

curl --data-binary '{"id":"curltext","method":"payto","params":{"destination":"mwLmd5xMnKkf4bBUa6MDrg4HYQaazoHtkj", "amount":"0.001"}}'

But I don't know what will be charged as fee. Is it possible to set the fee?

Seems like you are on testnet... INPUTS minus OUTPUTS = TX FEE.
So better to create a return adress. If there is only one UTXO in your wallet, and it has let's say 0.005 in it, by your line it would give 0.004 to the miners. So better to add a return address. You would have to add an address of your wallet.
I haven't worked out the params field, but there should be an option to add a second param for output address?


How do I consolidate all my BTC into a single address? I'd like to archive all my coins in a single address (specifically the address for a "brain wallet").

What is the most effective way to combine all the outstanding balances into a given address?

Once you have the address you'd like the coins to be in, just make one transaction for the total amount of your balance going to that address.  The inputs from all transactions leading into the sending wallet will be combined into a single output automatically.  Or are you asking how to create the brain wallet in the first place?


How long does it take to propagate a newly created block to the entire Bitcoin network and why? Once a new block has been created, it is propagated to the entire network. I’d like to know how long this would take “on average”.

The propagation delay can be from several causes, and I’d additionally like to understand which one is the most significant:

As I understand, blocks are not propagated before being verified and accepted, so this should contribute to propagation time.
Network latency adds delay regardless of the block size.
Bandwidth limitations: large blocks will take longer to transmit, and nodes with many outgoing links will take longer to transmit the block to all their neighbors.
The network’s diameter.

If there are other causes of delay I’d love to hear about them.

Also, is anyone monitoring the network’s propagation delay, or any of the other network measurements I mentioned, and if so, where can I find statistics?

According the paper 'Information propagation in the bitcoin network.' by Decker and Wattenhofer. The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block. This paper goes into some of the causes of propagation speed.

Block size is a dominating factor:

  "For blocks, whose size is larger than 20kB, each kilobyte costs an
  additional 80ms delay until a majority knows about the block." -'Information propagation in the bitcoin network.'

Network Diameter does not appear to be that important as there are some very long shortest paths in bitcoin, but those paths only represent a tiny faction of the overlay network.
The bitcoin network appears to be extremely well connected for most of the nodes and with a long narrow tail very very poor connections. A block may take a long time, possibly minutes to reach the last 0.0001 percent.

Bitcoin Stats have a nice website that measures block propagation speed, it is based on the research of Decker and Wattenhofer.
It doesn't entirely agree with the Decker and Wattenhofer paper but it is important to understand that the bitcoin network is evolving at a breakneck pace. The bitcoin overlay network like the weather or the stock market, has the property that what was true yesterday might not be true tomorrow.

Bitcoin Stats says that for today, the mean was 5.1 seconds and 90th percentile was 22.4 seconds.


I'm new to Bitcoin, how do I keep my bitcoins secure? With the recent rally and media attention, lots of new people joining the Bitcoin community.

A lot are asking:

I'm new to Bitcoin, how do I keep my bitcoins secure?

and if they aren't that's the first thing you should teach them.

Use a desktop or mobile wallet (Electrum or Mycelium) to spend bitcoins (be sure to write down your recovery seed and store it like a paper wallet). To receive and store them, use offline paper wallets. As soon as a paper wallet exceeds some amount (50mXBC for instance), put it in storage and start a new one. If you are spending and your online wallet runs dry, break open a paper wallet to complete the transaction, any leftover coins will remain on the online wallet.
NOTE: with "online wallet" I mean wallets like Electrum and Mycelium, not web wallets like Coinbase or the Blockchain.info wallet.
Someone posted instructions for paper wallets on bitcointalk:

https://bitcointalk.org/index.php?topic=1559277.msg17075677#msg17075677

Do your own research before risking your coins following what someone told you.

Do not use web wallets.

EDIT: Brain Wallets (memorizing a passphrase that is hashed to produce keys and addresses) are highly controversial in the bitcoin community. The proper way to use them is to choose the passphrase uniformly and at random from a large set (at least 2^128).
Security improvements include:
Adding salt (something unique but trivial to remember, like your full name, phone number, or email address) to the passphrase to prevent hackers from attacking everyone at once.
Using key stretching WarpWallet is an algorithm that derives keys from a passphrase using a difficult, memory-intensive algorithm, this makes them much harder to hack.

To generate multiple wallets from one passphrase, you can attach an index to it (append a number to the passphrase).

The main advantage of brain wallets is that there is no physical wallet to steal or confiscate, and plausible deniability of having bitcoin.
Disadvantages include difficulty of remembering the passphrase (if you forget it, the coins are gone), possibility of theft (there are hackers constantly monitoring addresses created from weak passphrases, and they steal coins immediately), and the fact that in the unfortunate event of your death, your family would not be able to recover your coins.
If you decide to use them, they can be used in place of the paper wallets in the first paragraph.


Mastering Bitcoin: Where is the checksum coming from when running bx base58check-decode? For example, if I run bx base58check-decode with the base58 encoded private key of Kxj5ejwPg2s2ejZHW7N1zAydD4fkmFi9j19QRmgeVK9mXL3wFMmp from this example, I get the following:

{
    checksum 2274467570
    payload 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b982401
    version 128
}

The payload, as well as the version, make sense to me; however, if I convert the checksum to a hex, it doesn't match the checksum of F29E9187 that I'm expecting, i.e., I understand how to form it per this question. But I don't understand how 2274467570 and F29E9187 are related.

decimal to hex, and then reversed ordering:

$ echo "obase=16;2274467570" | bc
87919EF2

reversed:
87 91 9E F2 -> F2 9E 91 87


Can an attacker use a modified Bitcoin node to pass fake transactions into the mempool? Is it possible for a malicious attacker to download a bitcoin software code, modify that code and use that software for his own benefit? I know that any changes implemented in the bitcoin software must be accepted by the majority nodes in the bitcoin network. But, here, consider that the malicious attacker doesn't need to use that modified version of bitcoin software by other users.

Here is an example, Suppose B is a malicious miner. He wants to modify the verification conditions(20 rules) of transactions. Then, he edits the code of bitcoin software to set his own verification rules for transactions so that he can bypass all the invalid transactions from his accomplices to mempool. Is it possible?

[The miner] edits code of bitcoin software to set his own verification rules for transactions so that he can bypass all the invalid transactions from his accomplices to mempool. Is it possible?

Yes and no.

Yes, it is entirely possible to modify the code to include whatever sort of transaction validation rules you want.

No, you cannot use this to trick the rest of the network into accepting your invalid transactions. Your node would be banned by other nodes in the network, since it is not following the rules of the network. The network is formed by the connections of thousands of individual nodes, that all follow the same rules. If a node breaks those rules, then the rest of the network will simply ignore them.

By changing the validation/consensus rules, you would effectively be creating a new altcoin network.


What algorithm do bitcoin miners use to choose which tx to include in their block? I understand it's in the miner's best interest to receive as many fees as possible for his hopefully-accepted block, hence it should include the most rewarding (fee / size) txs - up to the 1MB limit.

However, what algorithm do the miners use? It seems like a knapsack problem, which is NP-Hard, so I doubt miners actually go for the optimal solution.

Thanks!

No. this is not knapsack problem and no one need to find optimal solution.

Sort your transactions in mempool by two rules:

subsequent transactions can not be to the left of parent ones
most profitable transactions (fee/size) gravitate to left

and take leftmost transactions from mempool until 1 mb limit


Can you send a Bitcoin transaction to a Bitcoin address that does not exist? Say I arbitrarily pick an address "abcdefg" (for example's sake), which does not exist in the network; no one "owns" the address.

What happens when I attempt to make a transaction to this address?

Is the transaction rejected by the network?

If not is this transaction stored in the blockchain?

Can you send a bitcoin transaction to a bitcoin address that does not exist?

Absolutely, however, the address must be valid.

A completely arbitrary address (or a typo) will likely not be valid because addresses contain a checksum when they are Base58 encoded. There is no way for the network to know if someone owns a key corresponding to an address unless a transaction has occurred with that address. See Bitcoin Wiki - Address and BIP 13 which describes how a Pay-to-Script-Hash address is formed, as an example:

base58-encode: [one-byte version][20-byte hash][4-byte checksum]


How does nix-bitcoin provide greater security for installing Bitcoin nodes? nix-bitcoin claims on its GitHub repo to facilitate the installing of Bitcoin nodes and higher layer protocols (e.g. Lightning) with increased security? How does it do this?
[edit: as RedGrittyBrick points out below this project is a work in progress as of time of writing (August 2020)]

nixbitcoindev explains here that the additional security provided by nix-bitcoin is due to minimalism, code reproducibility, compartmentalization and defense in depth.
nix-bitcoin uses NixOS which is a purely functional operating system which means that it builds the entire operating system from the source code of every application of the Linux kernel resulting in the same system every single time it is deployed.
With a general Linux distribution it is not possible to de-install all the packages you don't need as it would eventually result in a broken system. NixOS has a kind of formula where it goes through and calculates what you need and only builds that. This minimalism significantly reduces the attack surface.
Everything is reproducible with NixOS, not only Bitcoin related software such as Bitcoin Core, c-lightning, lnd etc but the entire stack including the Linux kernel. As a result you know you have exactly the same system that everybody else has. That’s a really strong defense against  the developers inserting malicious code or code upstream getting compromised. Once the developers have verified the software, within the hash it’s going to be the same software that everybody is using.
Every service runs in its own little box under its own user. It can only see its own directory and with network namespaces it can't even scope out your entire network. It can only scope out its own network and its Linux namespace and the ones it is allowed to see. Outside processes outside of that network namespace also can't look inside. That offers a great deal of security because now programs like Spark wallet that connect to your c-lightning, they’ll never see JoinMarket, they’ll never see Electrum, they’ll never see bitcoind. They are maximally compartmentalized.
Defense in depth means putting up multiple walls or multiple lines of defense. nix-bitcoin isolates by users and isolates on the network level with systemd.


Who has copied or reimplemented Ripple? There have been almost an infinite amount of Bitcoin clones, but I have yet to see a Ripple clone or a Peercoin clone for that matter.  I'd include Nextcoin, but I don't think the full source has been released yet.

Is this correct?  If so, why not?

Ripple seems the most logical to clone because of the superiority of the code, and all one need do is generate a new genesis and checkpoint etc.

Are there a ton of Bitcoin clones because it has the largest market cap, and all want to get a piece, or does all of the undeserved bad rap that comes with Ripple repel clones?  That last logic doesn't hold much water when it comes to Peercoin.  Or is it harder to attract miners for Ripple because of the fee structure?

This makes no sense to me.  Why haven't the other major coins been cloned into oblivion like Bitcon?

See the list of forks on the Ripple wiki. It currently lists four projects.

As to why there are not more, any answer will by necessity be opinion based which tends to be not appropriate on a StackExchange site. But my answer would be that, as you say, producing an identical fork is trivial to do but also useless. The value of system like Ripple comes from network effects that a clone would lack. The only reason rational people would consider a using a fork would be if it had some important new feature (hard, lots of work) or if the existing implementation had some serious actual or perceived flawed that the fork did not (including possibly just the perceived control a specific entity may have on the network). For many issues people appear to have with Ripple, instead of forking it makes much more sense to work towards having a set of validators with a robust set of UNL entries that possibly exclude Ripple Labs and additional non-Ripple Labs contributors to the code base.


Is there any other protocol in use besides a "Gossip protocol" I'm interesting is there any other protocol that is being used inside Bitcoin network besides "Gossip"? And if there is, in which layer of communication and for which purpose is being used? Thanks!

If you want to read more about the p2p protocol, check out the Bitcoin Developer Guide's overview of all peer-to-peer messages. Besides transaction and block relay, it is used to announce node services, discover peers, communicate content preferences, and request specific content. Only blocks and transactions are gossiped. Node addresses are shared with connections that ask for them. The remaining messages are just for communication on specific connections. Note that other software may support additional messages not supported by the reference client, e.g. to serve UTXO data, or to fulfill service-specific light client requests.
FIBRE is a redundant second communication network for relaying newly mined blocks outside of the regular gossip. It used especially by miners and large Bitcoin services.
Mining pools use their own protocols (getblocktemplate, stratum, stratumv2) to coordinate contributions of their contributors.
The LN uses a whole separate stack of protocols to announce channels and nodes, manage peers, channels, and facilitate payments.
I am not sure whether the following strictly fulfill the definition of "protocols", but there are various coordination processes to facilitate multiparty payments such as PSBT, statechains, MuSig, JoinMarket, PayJoin, …

Hope that's sort of what you were looking for, but note that the list is not meant to be exhaustive. Please feel free to amend your question to further narrow down what you are looking for, if I am off target.


Duplicate of blocks in blockchain There is some strange TX

9c7b0d0423af64e81c4b850bae781e41077586a9e3328f5048f8367c6e4a8212

that doubled in blockchain local database.

Blockchain.info information is truly interesting. Is it a scum or what is it?

Two different blocks were mined at height 494676, i.e. two different blocks both naming the same previous block as their parent.  One of them has a hash starting 262f and the other is 6d0d.  Both of them included the 9c7b transaction.  This happens normally from time to time; for instance, it could be that 262f was mined first, but it wasn't relayed to the other miner fast enough, so they kept trying blocks with the previous parent and ended up mining 6d0d.  Or it could be that they were coincidentally mined very close to the same time.  The timestamp on 6d0d is 56 seconds later, but timestamps are not guaranteed to be accurate.

Only one of the two can be included into "the" eventual blockchain, so following this, miners creating new blocks had to make a decision as to which of the two to name as parent.  262f won, so 6d0d is now orphaned and is not part of the main blockchain; Bitcoin nodes won't consider it part of the authentic transaction ledger, and the miner who created it can't spend the block reward.


Tie Breaking in bitcoin transaction If two nodes broadcast different versions of the next block simultaneously , some nodes may receive one or the other first. In that case, they work on the first one they received but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer;

I got this information from the original publication about Bitcoin. But how long is this second branch saved in memory pool of nodes? How is this conflict resolved actually? Is there any paper mentioning this?

Most difficult (highest) chain wins. Side chains are stored forever just in case they become valid again.


Build bitcoin-qt on OSX I recently cloned from https://github.com/bitcoin/bitcoin.  I followed the documentation in  doc/build-osx.md.  I can build and run bitcoind without a problem.  But I would have expected to see bitcoin-qt built, but I do not see it anywhere.  Am I doing something wrong?  What is the build target for bitcoin-qt or, more generally, how do I build it?

Thank you so much.

You need to supply an extra option to compile a QT binary.

./autogen.sh
./configure --with-qt
make -j8

Your binary will then be in /src/qt/ as expected. To turn it into an .app you'll need to read contrib/macdeploy/readme.md and then run make deploy to wrap it in an application bundle ready for release.


Bitfinex api v2 not returning candles I am using bitfinex websockets v2 api in a Java application, to get the candles from a market. But I don't get any message back from the socket(not even an error).
I wonder what I am doing wrong. Also I noticed that I can't subscribe to the ticker.

v1 of the api works fine for me I can subscribe to messages with no problem. But in v2, I only get the ping pong to work but I can't subscribe to messages such as ticker or candles.

Let me show you the code that I have, maybe I am forgetting something:

Here I create a client and open a websocket to the new api address:

@SpringBootApplication(scanBasePackages = "application")
public class Application {

    private static Object waitLock = new Object();

    public static void main(String[] args) {
        ApplicationContext applicationContext = SpringApplication.run(Application.class, args);

        WebSocketClient webSocketClient = new WebSocketClient();
        webSocketClient.startWebSocketClient("wss://api.bitfinex.com/ws/2");
    }
}

This is the client that manages the connection to the socket

   public class WebSocketClient {

        final static CountDownLatch messageLatch = new CountDownLatch(1);

        public void startWebSocketClient(String address) {
            try {
                WebSocketContainer container = ContainerProvider.getWebSocketContainer();
                System.out.println("Connecting to " + address);
                container.connectToServer(WebSocketEndpoint.class, URI.create(address));
                messageLatch.await();
            } catch (DeploymentException | InterruptedException | IOException ex) {
                Logger.getLogger(WebSocketClient.class.getName()).log(Level.SEVERE, null, ex);
            }
        }

    }

This is the endpoint that I create to handle the responses

@ClientEndpoint
public class WebSocketEndpoint {

    private Session session;

    @OnOpen
    public void onOpen(Session session) {
        this.session = session;
        System.out.println("Connected to endpoint: " + session.getBasicRemote());
        RemoteEndpoint.Async asyncRemote = session.getAsyncRemote();
        asyncRemote.sendText("{event:\"subscribe\",channel:\"candles\",key:\"trade:1m:tBTCUSD\"}");
    }

    @OnMessage
    public void processMessage(String message) {
        System.out.println("Received message: " + message);
    }

    @OnError
    public void processError(Throwable t) {
        t.printStackTrace();
    }

}

The problem might be, that the JSON data does not contain line breaks. I was facing the same issue. My 'subscribe' call had no effect until I added line breaks to the JSON data. I haven't even gotten an error message back from the API.

You could use JSON library for Java which will handle the correct formatting for you.

Please note, there are some existing Libraries for Bitfinex and Java. You don't need to implement the API calls on your own.

https://github.com/timmolter/XChange (this one uses the REST API)
https://github.com/jnidzwetzki/bitfinex-v2-wss-api-java (this one uses the Websocket API)


Paper wallet generated client side and off network is not necessarily secure One would think that if a person generated a private key client side and never exposed that key to the internet, that they would be secure. However, the risk is that the paper wallet generation code is compromised such that it provides the victim with private keys that are already known to an attacker. How best to mitigate this risk?

You can generate the random bits yourself to eliminate possibly weaknesses / backdoors in an offline wallet generator. For example throw a dice 100 times and write down the sequence, and use the SHA256 hash as your private key. Or if you don't have a dice, toss a coin 256 times is ok too.


How much will transaction fees eventually be? Some people keep evangelizing that Bitcoin transaction fees are much lower than in PayPal or with credit cards.

However, once nearly all 21 million bitcoins have been mined, the network will still have to be secured.

But "miners" can then no longer be rewarded by newly minted bitcoins. They will have to be rewarded by transaction fees.

I read that the market will find the equilibrium how much these transaction fees will be.

Are there any estimates or more concrete calculations about that? Is it even possible to foresee, as the "degree of network security" is a rather nebulous incentive for most (casual) users? Will they thus be enforced by the software? Will these fees better be absolute or relative to the amount of a single transfer?

I read that the market will find the equilibrium how much these transaction fees will be.

It will not.  This is perhaps the biggest flaw in Bitcoin at the moment: once mining rewards end there is no direct linkage between the amount of hashpower needed to secure the network and the incentive to mine.

True, there is a limit on the blocksize, so if the transaction volume in a block window (approximately 10 minutes) exceeds the block size you can expect a miniature "auction" where transactions fight for space in the block by bidding up the minimum transaction fee needed to get in.  However this isn't really a closed-loop adjustment: the maximum blocksize is an arbitrarily chosen number, and there's no reason to believe the maximum blocksize is small enough to ensure that transaction fees are high enough to incent enough miners to mine to keep the system secure.  Unlike the difficulty and the USD/BTC exchange rate it does not respond to market activity.  It also has the negative side effect of capping the worldwide Bitcoin transaction throughput since other parts of the protocol rely on the assumption that blocks are created -- in the long run -- no more than once every ten minutes.

Compare this to the current situation with mining rewards: the more valuable a bitcoin is the more incentive there is for somebody to try to overwhelm the "good guys" by gaining 50%+1 hashpower.  However, the more valuable a bitcoin is the more miners will mine!  It isn't perfect, but the important point is that the demand for security increases the incentive to mine.  Note that although the difficulty will go up, that simply ensures that the reward granted every ten minutes is an approximately constant number of BTC -- the number of terahashes/sec fighting over that amount of BTC is free to respond to changes in their changing value (as measured in terms of all other goods in the world, including other currencies).

As the mining reward is reduced this "direct coupling" between the network's need for security and the incentive to mine becomes progressively more diluted.

I worry a lot about what will happen to Bitcoin once we decouple those two forces.  I think the developers ought to at least come up with a story on how this will be solved so people can start testing it.


Pending incoming BTC to Coinbase I sent BTC from lending platform to Coinbase on Jan 2nd.  Still shows pending.

Can anyone provide any info and assistance in getting this transaction completed?

f69f851197a7b9bd8cf3e85a2436ed51e1049fa4b277273e074708de34540288

https://live.blockcypher.com/btc/tx/f69f851197a7b9bd8cf3e85a2436ed51e1049fa4b277273e074708de34540288/

You can download Electrum and create new transaction from output with higher fee, it's called "Child pay for parent"

You hsould have access to oone of output addresses.


where can I get the NEW Hardware? to make profit Currently 2015 mid-October, how can I get the NEW hardware to actually make profit, after paying the electricity bill, ventilation, the cooling and all the extra cost?
I'm not aiming for $100 per day, but just anything above 3 Dollars per day will be fine. I've use the calculator websites to check the available chips in the market and after I input the hash rate and the Watt and the electricity cost, (which I happen to have for only 10 cents not 15), I still can't make profit.
am I doing something wrong or it's really getting impossible to make money out of mining now. thanks for any help..

No, you're not doing anything wrong. If it was easy to make a profit, everyone would do it, raising the difficulty, and bringing the profit to zero. Only those with the lowest cost of electricity, the lowest cost of capital, and who can get the best deals on high-end ASIC miners can make a profit. And even then, only by taking the risk that the difficulty or price will not change in ways they didn't expect.


New To Mining - How Much US$ Am I Making / Day? I am using a GTX 1050 ti SSC with fans at 100%. I got really lucky and this card might be the best overclockable one ever, I boosed performance by about 20%, when other people are happy to get 10%. Anyways, I am using MultiMiner and I am curious how much US$ I will make every 24 hours on average. The difficulty says 440.79B, price is Bitcoin, Profitability says 100%, Average is 386.21 MH/s, and Intensity is D. Thank you for help and is this good or bad?

First of all, are you trying to mine bitcoin?

And if you are then I am very sorry to tell you but trying to mine with 386.21 MH/s with the current bitcoin difficulty, means that you will mine close to no bitcoin. The power cost will be much higher than the mined bitcoin and thus will be unprofitable.

Currently, I am not aware of any person still trying to mine bitcoin with GPU's, I might be wrong, but the difficulty has gone up so much that it is not profitable anymore.

You can use this site to check your profitability, but as I said if you're trying to mine bitcoin I don't think you will find it profitable.


Is the synchronization process supposed to be downloading at less than 5kB/s? I've been running the bitcoin-qt client for over a week now trying to catch up with the block chain (closer to three weeks if I count the first time I had to synchronize everything).  Looking at my bandwidth usage, I'm only getting 2-5 kB/s at any given time.

I did a ton of Googling and noticed a lot of others were complaining about the long synchronization process, but none of them seemed to be as long as mine (and no one made mention of their speeds).  Is it supposed to be this slow, or have I set something up incorrectly?

I should further clarify that this is not a new issue, this has been persistent since I started using bitcoin over a year ago.

Further information:

The client is always at or below 8 connections to the Bitcoin network (if that is at all relevant/useful information).  I have UPnP enabled.

Computer: I'm using a laptop (OS: Win7 64-bit) from a few years back, so inherently the  specs aren't tops (but by no means terrible) - the CPU is an AMD Athlon II M300 (2 cores / 2 threads, 2.0 GHz, 1MB cache).

CPU Usage: According to perfmon, bitcoin-qt averages 7% CPU consumption.

Blocks processed: 124 in an hour (I also made a list breaking it up into 10-minute increments and it averaged 1.8-2.0 blocks per minute of those increments, so it agrees with the hourly rate without much fluctuation).

The synchronization process may be slow on slow computers - it does not only rely on bandwidth. After downloading a chunk of blocks from various peers, the Client needs to verify every transaction in them, which is a very CPU intensive task. If you have a slow computer, this will be the bottleneck - you will spend a lot of time verifying the block and only a little downloading them, making the average download speed small.


How Crypto Payment Processors Handle Wallet Balance Privacy? If an online store accepts crypto payments directly into its wallet there is a problem:

"Anyone can make a small transfer to any BTC address derived from the MPK so they can watch the store's and its client's funds as soon as the owner transfers funds from her wallet. I suppose possibly that the person who did this wanted to know if cracking the store worth the effort."

In a previous question a user replied that a solution to this is to use a crypto payment processor like BitPay but:

How they handle wallet privacy? Isn't it the same? The BTC only gets
to make a higher number of transactions between different addresses
but still, they can be traced to the store owner's wallet and her
client's afaik.
Or if the transaction is too small to match the price of the
purchase, BitPay returns the transaction to the originating address
and the BitPay address that accepted the transaction gets dumped so
it can't be used to trace BitPay's customer real address?
Another way I think this could be avoided as well is if BitPay
converts the payment to fiat, then to BTC again and then transfer the
funds to the customer wallet.
Wouldn't it be easier just to avoid payment processors and convert
the BTC to a privacy coin like Monero? For example using a
transitional wallet in the store to accept payments, making smaller
transactions to an exchange, converting to Monero and back to BTC and
then transfer to the owner's real wallet?
Could this method conceal the store owner and her client's wallet
balance to any potential hacker who makes a small transaction to any
store wallet MPK derived address?
Or the only way is to use a payment processor? If so, then how they
conceal their customer's wallet balance?

Thanks for your attention, it's a confusing subject for me and I hope to have written my questions as succinctly & understandably as possible.

First of all the initial assumption is incorrect. Just because you sent coins to one of my addresses doesn't mean you will see my whole wallet. My wallet software may incorporate those coins in a transaction but it may or may not include all the other unspent coins in my wallet. It'll select unspent coins according the amount I wish to send and incorporate only the ones needed to meet that amount.

The second thing is that it's hard to tell from the blockchain which addresses are part of my wallet and which ones aren't. So for example you may not be able to tell which outputs are change and which are intended for the recipient.

As for bitpay they generate their own addresses and don't ask you for your MPK. To get paid you have to initiate a withdrawal. They pay you in fiat if that's what you request or they send bitcoin to your wallet. They don't pay you after every transaction. Only the total amount when you ask for it.

Bitpay is totally regulated so you will have to comply with anti money laundering and know your customer laws.

There are no originating addresses in bitcoin. You certainly can't safely assume that sending money to the address where the transaction's inputs were previously sent is the same as refunding the sender. To refund the sender you ask them for their address.


Verification of Transfer Ok I have made bit Cash paper wallet ... Now I am going to transfer to it from my Trezor..  my question is how do I verify that what I transfered is on the paper wallet?

Thanks  Linda

You can use Blockchain Explorer and just search for your address either the source address from the Trezor HW Wallet or the destination one, the paper wallet's address.
You will be able to view the whole transaction and the balance in both addresses.
Note that transactions take some time to be included in a block 10-20 minutes, the bigger your transaction fee the faster your transaction will be included in a block.


signing multiple input raw transaction - algorithm and sighash types I have an unsigned raw transaction:
01000000020dcc23ccdb3665779a7657577cd33c5c0660e969ea2ffaf5438c58306ebc9dd20100000000ffffffff49508924c21b25ee2ff6aed61ccc202793aa992d3e033f12f2bf4a94d6346d010000000000ffffffff0240420f00000000001976a9140d7ca1e17524d6c96209cf503fb053613cecf8f688aca0f703000000000017a91452636ce984783dac880e139fa3b69b4d9be39ab68700000000

I have read these threads:
How to redeem a basic Tx?
Redeeming a raw transaction step by step example required
These threads explain signing a raw transaction with 1 input.
Questions
Do I understand correctly that both inputs are to be signed separately?
So first, we sign the first one, then the second one. To sign an input we replace scriptSig for this input with the scriptPubKey, that locks this input. ScriptSig for the other one remains blank.
It this correct?
But in both threads in step 13 something is appended at the end of transaction. It is called hash code type
What is this? Is this has anything to do with sighash type byte the one that is appended to the signature? If not how to determine this value?
What is the correct sighash type for the scenario I described above (signing inputs separately)?
Is this: 0x81 (SIGHASH_ALL | SIGHASH_ANYONECANPAY)?
Or should this be 0x01 (SIGHASH_ALL)?
I don't know which one is correct as transaction to be signed contains the other input (without scriptSig set but still, it contains it).

Do I understand correctly that both inputs are to be signed
separately?

yes

So first, we sign the first one, then the second one. To sign an input
we replace scriptSig for this input with the scriptPubKey, that locks
this input. ScriptSig for the other one remains blank. It this
correct?

yes

But in both threads in step 13 something is appended at the end of
transaction. It is called hash code type. What is this? Is this has
anything to do with sighash type byte the one that is appended to the
signature?

yes

What is the correct sighash type for the scenario I described above
(signing inputs separately)? Is this: 0x81 (SIGHASH_ALL |
SIGHASH_ANYONECANPAY)? Or should this be 0x01 (SIGHASH_ALL)?

Use 0x01 (SIGHASH_ALL)


What would it take to track dollars like bitcoins? Watching an ATM from a large US Bank accept a cash deposit makes me wonder - what would it take to track dollars like bitcoins?

Said another way, what would a blockchain for fiat cash look like?

When I deposit cash into this ATM, it scans each banknote.  It uses Optical Character Recognition to classify the banknotes by value.  I imagine that the ATM could recognize the serial number from the bill as well, and publish a corresponding transaction to a USD blockchain.

Well, in a sense cash-notes ARE tracked!! You've seen that scene in the movies when the "bad guys" ask for "non-serialized" bank notes as ransom? That's the exact reason: knowing dollar bills from e.g. serial numbers "AAA0001" up to "AAA1000" were given out as such payment allows a number of gov. organizations (from a number of countries) to track the movements of such bills, whenever and wherever they pop up at a legit commerce or bank that accepts them. And, of course, that allows these organizations to more or less track the movements of said people.

By asking for notes that don't conform to an (easily recognizable) set, the ability to track the where-abouts of the money (and hence, of the original people who receive it) is much reduced.

There are trillions of dollars in the world nowadays, about 8% of which exists as physical bank notes, millions getting lost/burned/teared on any day, and millions more printed. So no gov. agency would attempt to try follow the movement of any coin or bill - just the very much reduced set of bills known for being given as payment to "bad guys".


Bitcoin core HD wallet: how sensitive is the 'hdmasterkeyid' ? I have recently upgraded my bitcoind node to v0.13.0 and encrypted a new HD wallet:

$ bitcoin-cli getwalletinfo

I am getting some hdmasterkeyid hexadecimal number displayed on the screen. I have not yet done my homework on HD wallets and reading the relevant sections of 'Mastering Bitcoin' does not alleviate my fear: should I be worried about hdmasterkeyid being displayed on my screen? how sensitive is this number? I am guessing this is safe (as no password authentication is required to get this number) but I would like to make sure this is the case.

It is not sensitive at all.

In particular, it does not allow people to derive addresses, does not allow them to recognize addresses that are yours, and cannot be used to infer anything about your private keys.


Balance zero after recovering wallet from seed-phrase I recently got help my some experts on how i can recover my wallet using my private key, so i went ahead and downloaded brd wallet and block chain, then proceeded to recover wallet in the first and recover funds in the latter, but both brought up my account with zero funds in it.

I am a bit confused and worried now as i just made that payment i dont know how i can go about it, and secondly if i get the Qr code of my old wallet and i scan it into blockchain addresses and it comes up as non- spendable, and i am being told to scan my private key if i have it in written how can i go about unlocking that...

Original question: I forgot which software I created my wallet with. How can I recover from a 12 word seed phrase?,

I ... downloaded BRD wallet ... then proceeded to recover wallet ... but [it] brought up my account with zero funds in it.

Choose Sync Blockchain (Menu > Settings > Sync Blockchain).
Wait five hours
Check balance

If not try

Uninstall Bread Bitcoin Wallet.
Reinstall Bread Bitcoin Wallet.
Bread will ask you to type in your 12-word key in order to re-instate your Bread Wallet.
Now your balance should show as $0.00. This is normal.
Sync Blockchain (Menu > Settings > Sync Blockchain). Note: takes several hours.
Bitcoin balance should now be displayed properly.

From https://www.reidwalley.com/fix-bread-bitcoin-wallet-not-importing-paper-wallet/


What does bitcoin actually do with these problems? I understand this might be a simple question but what do cryptocurrency companies do with these problems when you mine. I know you get reward for solving a problem but what will bitcoin do with that?

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


Blockchain.info websocket not working I have been trying to get this code to work and I get a blank page no response at all from the server what is wrong with the code? or has blockchain.info changed something in their code? Can some help???

Here is the code i'm using : http://btcthreads.com/websocket.html

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

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

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


What determines SHA256 performance on different types of hardware? I know the answers to many questions on here briefly touch on this point, but I'd like to get a consolidated answer that really touches on the key differences between different types of hardware which allows SHA256 to perform better, instead of the less-related tangents other questions discuss. While my immediate concern is with Bitcoin, I know that some other crypto-currencies use different algorithms, so feel free to reference them if it helps make your point.

Why does the Bitcoin hash algorithm, SHA256, perform better on different types of hardware? What makes an ASIC/FPGA capable of computing more H/s than a GPU, a GPU than a CPU, etc?
What is "the complexity of the cores?" Is this a reference to the number of cores, or to the actual die complexity? In both cases, why is this not a factor in SHA256 performance? Referencing David Perry's answer here:

  It's important to note, by the way, that the one thing that won't buy you more hashes per second is the complexity of the cores. This is why Nvidia may make great cards for gaming purposes, but they suck for mining - games make better use of exotic new instructions than SHA256 does.

Can SHA256 be optimized at all to perform better on a per-architecture basis? Can any optimizations be made to the double-hashing process?

Mining performance can be viewed as consisting of two factors. One is the total resources available. The other is what fraction of those resources you can usefully apply to mining.

ASICs and FPGAs excel at mining because you can effectively use a very high fraction of their available resources for mining. CPUs are terrible at mining because a huge fraction of their resources are useless for mining -- they're optimized for memory access, decision making, floating point math, and many other things that don't help with mining at all.

The "complexity of the cores" refers to how sophisticated the operations that the cores can do are. This doesn't help with mining, which only requires very simple operations, and thus just increases the fraction of the resources available that you can't use for mining.

SHA256 can be heavily optimized for every architecture. In the early days of mining, there was a huge "arms race" to micro-optimize mining for various architectures.


Print wallet.dat with base64 I just wanted to ask If it makes sense if I want to print out my wallet.dat to encode it with base64?

I also read that the backup would become useless, if I get any receivements or make deposits and I would have to print out the wallet.dat again?

I would like to encode my wallet.dat with base64, print it and hide it in safe.

when my laptop breaks down and my other backups are also damaged (why every), i could scan my printed wallet.dat with OCR, decode it with base64 and just load it into the normal bitcoin client?

does this sound correct?
or are there any things I'm missing?

I dont want to rely on other software, no other web apps or key/password generators...

You are correct, and this is possible.

To summarise the wiki info on wallets, you can backup the wallet in any form you like in order to preserve the key pairs, transaction history and other useful information. The wallet may become badly out of sync but the backup is still fundamentally usable.

As wallets are often implementation-specific and needn't be distributed in the same handy fashion as Bitcoin addresses, your wallet.dat can be fairly large. The Base64 size of your wallet printout will be 4/3rds of the normal wallet size in bytes.

Six point font is smallest reliable size for most OCR applications. If I assume you are using the A4 standard, an single A4 page of 6pt monospace font can contain approximately 20,000 characters or 15 kilobytes of Base64 data. Duplex would make that 30KB per page.

Alternately you could use Version-40 QR codes, the information density per page could be several times higher. Finding an off-the-shelf open source tool for version-40 QRs could be hard, so you would be relying on third-party software; conflicting your question requirement.

When printing to paper instead of plastic, consider flame retardant paper treated with a safe insecticide to reduce the possibility of losing the key to insects or mild fire. Putting the printed key inside a black envelope inside a tamper-evident bag would also be a good idea.


Using ASIC for password cracking - mad concept? All ASIC for Bitcoin do a double SHA256 hash on an arbitrary string. But maybe they might be used for pen testing :-)

Lets assume we have single SHA256 hash we want to crack. We also have an ASIC that does double SHA256. Well if we compare results computed by double SHA256 to passwords that generated SHA256 hash we will get nothing. But what if we do single SHA256 on SHA256 hash that we got on start using CPU, and then try to find SHA(SHA256(x))? If we find goodX it would be our password.

Would modifying firmware, or just mining proxy that feeds miner with work do the job?

It will not help even if passwords were hashed with DSHA256. This link explains why. https://rya.nc/asic-cracking.html

Basically the ASIC loads the header into its memory and increments the nonce until the hash of the header is lower than the the specified target.

Therefore you cannot use this to brute force a password seeing as the logic is incompatible.


Procedure for Deriving Payment Addresses I'm trying to understand the HD wallet payment derivation procedure, so assume:

Ownership of a Bitcoin HD Wallet on an external smart device
Exported account level extended public key (xpub....) from the first account.
Derivation Path "m/44'/0'/0'/0/0"

What is the step-by-step procedure that one would use to derive a valid bitcoin payment address that can be confirmed with the external wallet?

The process, according to BIP32 - Child key derivation (CKD) functions, seems simple and straight-forward enough that it should be able to be written as a single function in any programming language with two processes: Base58 and HMAC-SHA512, which are such standard functions that I don't believe that it's necessary to install a platform tool and a bloated spaghetti code library to perform the derivation.

UPDATE 20190718:

Here's what I've been able to cobble together from various sources. PHP code and reference source for the derivation process:

<?php

  // https://iancoleman.io/bip39/ - Downloaded and used offline.
  // Bip39 Test Mnemonic: abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

 $Pub = "xpub6BosfCnifzxcFwrSzQiqu2DBVTshkCXacvNsWGYJVVhhawA7d4R5WSWGFNbi8Aw6ZRc1brxMyWMzG3DSSSSoekkudhUd9yLb6qx39T9nMdj";

 $Index = "00000000";

 $ExtPubKey = bin2hex(base58_decode($Pub));

 $Type = substr($ExtPubKey,0,8);

 $Depth = substr($ExtPubKey,8,2);

 $Fingerprint = substr($ExtPubKey,10,8);

 $Account = substr($ExtPubKey,18,8);

 $ParentChainCode = substr($ExtPubKey,26,64);

 $ParentPublicKey = substr($ExtPubKey,90,66);

 $PubChecksum = substr($ExtPubKey,-8);

 $PublicKey = hash_hmac('sha512',$ParentChainCode,$ParentPublicKey.$Index);

 $PublicKey = "04".$PublicKey;

 $PublicKeyHash = hash('ripemd160',hash('sha256',$PublicKey,False));

 $BaseAddress = "00".$PublicKeyHash;

 $PreChecksum = hash('sha256',hash('sha256',$BaseAddress));

 $Checksum = substr($PreChecksum,0,8);

 $Address = $BaseAddress.$Checksum;

 $PaymentAddress = base58_encode(hex2bin($Address));

 echo "Payment Address: $PaymentAddress\n";

?>

I'm using xpub to prove that the procedure works. Ultimately would like to be able to derive for ypub and zpub.

It seems like I'm just missing something important, like maybe variable typing, maybe binary something...I'm at a loss.

I've been told by Andreas that there's something about adding two numbers together, but I'm not finding the reference to it.

One source referenced something about elliptic curve and a mystical variable "G" but with no explanation.

According to BIP32, this process is supposed to be really easy.

Any assistance would be appreciated. TIA.

The method for deriving child keys from extended keys is specified in BIP 32.

Note that the specific derivation paths for xpubs, ypubs, and zpubs are not defined by BIP 32 but rather are constructions created by Electrum and SatoshiLabs. These have a specific meaning described in SLIP 132. Their encoding is the same as described for xpubs in BIP 32 but with a different prefix byte.


Bitcoin config file to setup bitcoin node in testnet network in ubuntu I am new to blockchain, I want to setup my node in testnet network in my ubuntu machine.

I am using this below mentioned bitcoin.conf file. Is this the correct format to sync the node faster?  Or I need to do the changes in this config file.

testnet=1
dnsseed=0
upnp=0
setgenerate=1
blocksonly=1

port=12000
rpcport=5000

server=1
prune=1000

rpcallowip=0.0.0.0/0

rpcuser=someuser
rpcpassword=somepass

I am referring this link to setup my bitcoin node https://www.codeooze.com/blockchain/bitcoind-running-in-docker/

In general, you can use Lopp's Bitcoin Core config file generator to set up your Bitcoin Core config files. Parameters are collected in groups by topic (e.g: Mining, Networking, ...). Moreover, each parameter contains a description of what it is used for and what is it's default value.


What is an accepted standard for a Bitcoin system secure from loss? Using Bitcoin, you can have transactions sent to different addresses. These addresses are, in turn, contained in wallets accessed by keys. The downside is, if you lose the keys, you will lose the Bitcoins (purchasing power) at those addresses in those wallets.

What constitutes a widely accepted and reasonably safe backup system for the keys? Are there means of storing or "hosting" the keys in a way that most authorities would agree has minimal risk of loss?

The most common approach seems to be backing up your (encrypted) wallet on cloud hosting services such as Dropbox and Google Drive. To reduce the risk of theft, use a very strong password to encrypt your wallet, and do not store the password anywhere less secure than the password itself (e.g. if you use a password manager, it should also have a very strong password).

To reduce the risk of accidental loss, keep backups in multiple places. E.g. Dropbox, Google Drive, email it to your family and friends, back it up to an external hard drive; if one of these disappears, chances are still good that you can recover it from another source. You don't want the keys to be in only one physical location...e.g. having the only backup be in your house means that a house fire or theft could mean you lose your bitcoins.

Just don't forget the password! Maybe you should write it down and keep it in a safe deposit box at a bank, and/or keep paper wallets there, if it's worth the cost to you (maybe $15/year for a small box).

A rather different approach is taken by deterministic wallets like Armory and Electrum, which generate one root key or seed and then generate your private keys and addresses from that. Armory's root key works on the idea that you print out the ~256-bit root key in one or more fragments, and need the appropriate paper records to restore your wallet. Electrum's seed is a 128-bit number represented by 12 common words, which you commit to memory and/or write down. Securing these records would follow similar guidelines to a written password or paper wallets.


How to recover coins from a wallet that uses BIP32 Deterministic Keys? Say I am using an online wallet that uses BIP32 deterministic keys and the site goes down. I have a backup of my seed (passphrase). Is there a github repo that I can download, run on an offline computer, present it with my seed, present it with the BIP32 Path: m/44'/0'/0'/0/2 and recover the private key associated with that seed/path so that I can transfer the funds out of it?

Here's a web tool for BIP32 key derivation.

The only problem is the hardcoded 50k rounds of HMAC-SHA256. You do need to know how your wallet software exactly derived the master private key from the mnemonic or you'll get totally different keys. Unfortunately there's no standard convention for the HD wallet backup/restore process and I'm afraid this ranks quite high among the biggest downsides against Bitcoin adoption.


What is a step by step way to insert data in OP_RETURN? I was following https://bitcointalk.org/index.php?topic=453086.0
for creating a message in OP_RETURN. I am able to decode my raw transaction, but on signrawtransaction it gives

  error: {"code":-22,"message":"TX decode failed"}

I validated the address, is there something that is missing in that tutorial.

I wrote a little demo program which puts a snippet of data into an OP_RETURN script. It requires a bitcoin instance that accepts RPC connections, though it could be implemented without that. You can find it on github here. It's been tested, but only on testnet. I'm going to go through the code and explain what it's doing.
Start
[...]
logging.basicConfig()
logging.getLogger("BitcoinRPC").setLevel(logging.DEBUG)

This makes logging more verbose. It's handy because it shows what RPC calls are being made.
Connect to bitcoind
rpc_user = "bitcoinrpc"
rpc_password = "87Y9A2gs25E9HDPGc9axqSqzxMR2MyTtrMkYc5KiZk2Z"

rpc = AuthServiceProxy("http://%s:%s@127.0.0.1:18332/" % (rpc_user, rpc_password))

Note that your password will be different, and that you use port 8332 for mainnet instead of port 18332.
List unspent outputs
first_unspent = rpc.listunspent()[0]
txid = first_unspent['txid']
vout = first_unspent['vout']
input_amount = first_unspent['amount']
SATOSHI = Decimal("0.00000001")
change_amount = input_amount - Decimal("0.005") - SATOSHI

The - Decimal("0.005") part is so that we pay a transaction fee.
Create transaction
# Marker address we're going to replace
# Produces a pattern that's easy to search for
mainnet = 0
if mainnet:
    dummy_address = "1111111111111111111114oLvT2"
else:
    dummy_address = "mfWxJ45yp2SFn7UciZyNpvDKrzbhyfKrY8"

These are two different encodings of a Pay to Public Key Hash of all zeros. The top one is the mainnet representation, and the bottom is the testnet representation.
# My change address
change_address = "mhZuYnuMCZLjZKeDMnY48xsR5qkjq7bAr9"

Remember, this is my change address. If you don't change it, you'll be sending money to me.
tx = rpc.createrawtransaction([{"txid": txid, "vout": vout}], \
                              {change_address: change_amount, \
                               dummy_address: SATOSHI})

And now we have an actual transaction. It doesn't contain any of our own data though, so we'll have to fix that.
Replace dummy output with our own output
# Pattern to replace
# Represents length of script, then OP_DUP OP_HASH160,
# then length of hash, then 20 bytes of zeros, OP_EQUALVERIFY OP_CHECKSIG
oldScriptPubKey = "1976a914000000000000000000000000000000000000000088ac"

This is a bit of a hack. Instead of creating our own output, we create a dummy output, then search for the pattern it makes and replace it. There's probably a better way to do this, but this seems easiest.
# Data to insert
data = "Melons."
if len(data) > 75:
    raise Exception("Can't contain this much data-use OP_PUSHDATA1")

newScriptPubKey = "6a" + hexlify(chr(len(data))) + hexlify(data)

Next we create the data we want to put into the blockchain. I'm using the string Melons., but you could use anything. (Above 40 bytes is nonstandard, though.) I covered most of this in my other answer.
This code will break if the data is longer than 75 bytes. If you need it for more than that, you could use OP_PUSHDATA1 instead of the single-byte pushdata that I'm using here.
#Append int of length to start
newScriptPubKey = hexlify(chr(len(unhexlify(newScriptPubKey)))) + newScriptPubKey

This part is a little different than my other answer, because we need to include the length of the scriptPubKey also. This code will break with data longer than 251 bytes. If you want it to work on data longer than that, encode a varint correctly.
if oldScriptPubKey not in tx:
    raise Exception("Something broke!")

Error checking for this very rickety method.
tx = tx.replace(oldScriptPubKey, newScriptPubKey)

Finally, a string replace swaps the new script for the old one.
Sign it
tx = rpc.signrawtransaction(tx)['hex']

Bitcoin handles the heaving lifting here.
Broadcast it to the network.
rpc.sendrawtransaction(tx)

Done! Now just wait for your transaction to get into a block.
I ran the code (output), and I produced a transaction, which you can see in Block Explorer here. If you copy the string next to OP_RETURN, and paste it into a Hex to ASCII converter, you get...
Melons.

Done!
Other resources
I found this webpage helpful while writing this.


Security implications of regular saving into cold storage I am thinking about following this plan:

Regularly buy bitcoins in an online exchange, 100€/month at market prices.
Once the balance in the exchange exceeds a certain limit (500€), move those bitcoins to cold storage, as long-term savings.

(the reason why I want to do 2 is that I do not feel I really own bitcoins until they are in a wallet under my control)

With this scheme I would be transferring to my cold wallet a couple of times per year. I have read that reusing a bitcoin address is not recommended. I am worried about these two facts:

Will reusing my cold-storage address decrease the security of my cold-storage wallet?
The balance of the offline wallet will be visible on the blockchain. I have read about privacy implications of having several parties transfer to a single bitcoin address (employer being able to see my rent, for example), but since the only one transferring to this account will be myself, from the account in the online exchange, there is no danger of private information becoming public, correct? That is, from these regular transfers no spending habits can be inferred. Furthermore, the receiving address will not be linked to any real persona. The only one knowing the identity of the sender is the exchange, and the identity of the receiver (the cold wallet) is completely hidden since he is not engaging in other transactions with any other party. Is this correct?

Note: I am not planning to spend from the offline wallet at the moment, and I know that spending changes the security and privacy implications. I am planning to only save into the offline wallet.

Q1: Depens on how you use it.
Transactions to an address does not decrease it's security.
Using a cold-storage wallet and taking it online exposes your wallet and it's security.

Q2: It's correct. Most exchanges require KYC(know your customer), they store information about you and your withdrawal addresses. It's possible to create a new address for each withdrawal. It's hard to prove that you are in possession of the withdrawal address.

  (the reason why I want to do 2 is that I do not feel I really own bitcoins until they are in a wallet under my control)

Can't stress this part enough, you only own bitcoin if only you own the private keys.