You mean the intermediary addresses only owned by BitPay? I mean, the ones in the invoice forms.

Not true. You provide your public address, no private keys are involved for receiving payments through BitPay.

You'd better go with a serious service like BitPay:

https://bitpay.com/api

Blockchain.info has the most broken API ever, you're bound to be alone in the dark. Let it just rot.

Long-term scalability first, mobile/embedded usability second. Failing at scalability would eventually leave Bitcoin in the hands of "the rich ones" (namely Google etc.), which makes for an even worse scenario than banking system. Relying THAT much on processing power or disk space is a doomed solution to me.

Generally speaking, it seems that Bitcoin keeps afloat based on ridiculously optimistic predictions, whereas any software in the world is written with a constant eye on worst-case scenarios.

Hi,

a few days ago I finished writing my blog series about the basics of Bitcoin programming.

In the last two years, I sort of hated that every tutorial I read couldn't teach blockchain development from the very start, I mean without taking for granted what a transaction is. Beyond that, lot of theory without practice. Everybody seemed so confident about the subject, yet I felt that no one was really paying attention to uneducated readers like me.

These were only some of my unanswered questions:

- How does a private key hold bitcoins?
- How an address is supposed to receive bitcoins?
- What the hell is a scriptPubKey and scriptSig?
- What about all those numbers and hexes?

So, after spending a lot of time looking for total beginner resources and failing at that, I felt I could somewhat fill this gap. Mine is a slow-paced bottom-up tutorial whose aim is teaching you to consciously build, sign and publish a basic raw transaction to the blockchain.

http://davidederosa.com/basic-blockchain-programming/

All sample code is written in C language, easy to read, easy to compile.

https://github.com/keeshux/basic-blockchain-programming/

I plan to dig further into the subject in the near future, but meanwhile it'd be great to have some feedback. If any article is not *that* clear, feel free to leave a comment and I'd be happy to reply.

Thanks,
Davide

Autoreply: yes, by having 64/80 bytes worth of hashes (previous block hash + Merkle root). Thanks Tier.

Good point. Before testing, would you state the same for a Bloom-filtered stream though? Do you think that block headers alone would compress as bad?

Just out of curiosity, I wonder why the Bitcoin p2p protocol doesn't support any data compression. It seems to make sense in the first place as miners exchange a lot of data, possibly with many repeated patterns. Is there anything I didn't consider? Prefer network usage over processing power?

Thanks!

Oh, nice. Can we also expect the getblocks message to be deprecated some day along with this improvement? I don't see any other use than legacy from now on.

One more thing: I currently sync both headers and blocks with a single node and I'd really like to take advantage of the parallel download, but I don't get the 'moving window' approach in detail without diving into the Bitcoin Core code. I'd very naively guess you're requesting one or a few different blocks at a time from each connected peer to fill the 'window' and you only keep moving it (going for higher heights) as the lower side of the window is filled (i.e. older blocks are downloaded). Another fix for multiple download would be assuming the blocks may come in an unordered fashion. Is this optimal for SPV or even correct at all? Perhaps a much wider window due to the trivial size of filtered blocks?

I wonder if anybody out there has already moved or tried to move to the recent headers-first sync process as described by sipa.

What's the status? Is the addition ready for inclusion in wallet software? Any wiki to learn more from?

Thanks!

I would consider "slow" a database query that takes that much. That's why a nice indexed structure is a huge advantage and several tools certainly exist to build an efficient blockchain database and execute fast queries on top of it. Unless it's about practicing, as Buffer Overflow pointed out.

Not intrinsically slow, probably slow when run on 20GB of unindexed data..

You'll be only able to get such information about an address if you have a full node history locally. Given that, the overall process is:

• Parse blocks from files
• For each block, iterate through all transactions
• For each transaction, parse output scripts
• If the output script is of some standard form, you can get an address out of its bytes
• If the parsed address matches the one you're interested in, add the transaction to your "interesting" set
• From the relevant transactions you can finally infer all the stats you need, e.g. balance, sent/received..

This is just a generic slow algorithm because I don't know the structure of Bitcoin Core files. Some existing index would surely improve search efficiency (e.g. the UTXO index is enough for the balance), in fact web providers must have some internal index on addresses. I've seen many tools around that build fast databases from raw blocks, but I've never used them.

If you don't have any local history, the only way I'm aware of is loading a Bloom filter matching your address and scan the whole blockchain. The peers will then send you relevant transactions for that address plus some unrelevant ones due to the probabilistc nature of the Bloom filter. Beware that you will be forced to do a full rescan for each new address you want to search.

Oh my.. it's getting clearer that you two didn't understand a word of what I said. I'm giving up, good luck!

Again: a height-to-hash translator might be useful in general, still it's no use for SPV wallets.

If you already know how to sign the transaction given your input keys, you only need a library that can do BIP32 derivation from the master private key. Several exist, what's your programming language preference?

JavaScript: bitcoinjs, bip32.org
Java: bitcoinj
Objective-C: WaSPV, CoreBitcoin

If you read carefully I moved the problem to the FCU simply because it's pointless to set a checkpoint without considering the FCU, unless you intend to support raw monitors that only observe upcoming blocks and transactions.

I don't see any advantage for SPV wallets with some history, whereas a protocol message providing a (timestamp -> checkpoint_hash) mapping would be much more useful for both monitors and wallets. By checkpoint_hash I don't mean "the first block with transactions", rather a checkpoint block the way you meant in your previous posts.

Example: "hey peer, I want to start syncing from 'Jan 01, 2012' (or from now on). I don't have any idea about what the hash of the first block to start sync from could be, can you give it to me?"

Thanks fbueller, very useful information. Lurking around I stumbled upon BIP 33 that could even provide a solution at the Bitcoin network level. Is this scheduled for implementation in Bitcoin Core?

That's certainly an example of user-friendly format to start from. The point is: despite being that simple, most software seems reluctant to import it in an automated way.


Exactly. I had originally posted this question on StackExchange where I complained about HD wallets in particular. The only significant barrier is defining some default derivation behaviour (e.g. 100k rounds of SHA256) and gap limit to reduce paper backups to just mnemonics. Creation time is a mere optimization and can be optional, but any custom parameter must be exposed no matter what. As to the branching structure BIP44 is a good candidate too and it defines a default gap limit of 20 that sounds reasonable for most users.