Yes exactly  - see edit

Block locator is a list of block hashes that you know about, starting from your head, back towards the genesis block. The idea is that the remote peer can know which blocks/headers to send you. If it determines that your most recent blocks are actually now on a side chain, then it will work backwards through your block locator to find a block which is on the main chain and then send you blocks from there onwards. If it cannot find any blocks in your locator which are on the main chain, it will send you blocks from the genesis block.
Current implementations create a block locator roughly as follows,


So many more recent blocks are added, and as you work back, the steps get bigger (because of the decreased likelihood of deeper and deeper reorgs).
When downloading the headers before the last checkpoint, you can simply use the hash of the most recent header you have as the locator, i.e. only one hash.

EDIT:
As for working backwards, this is not possible. What is possible however is to hardcode checkpoint hashes, this way you can download the headers between each checkpoint separately enabling your parallel download. I have code to do exactly this, but I haven't bothered to test it to see if the speed improvement was worth it compared to downloading from a single peer. Others may see this as a waste of network resources perhaps.

To take out the bitcoin network, you only have to attack the relatively few nodes that allow incoming connections, most of which are running on commodity hardware at users' homes. Taking out one of the largest sites on the internet is a completely different story.

Also, the bitcoin network provides no guarantees about the accuracy or security of the data it carries - so you gain nothing from getting your data from it compared to from some other source. That is in fact, pretty much the whole innovation of Bitcoin - that each node can arrive at the same globally consistent view, with zero trust of anyone else on the network, instead determining for itself whether it thinks the data is legitimate.

24 more blockchain wallets?

in ../node_modules

should pull in everything it needs though.

Attaching messages to transactions that get stored in the blockchain is highly wasteful and won't be implemented.
However, what will be possible in the next version is something like you want: Instead of making a payment by taking the payment address, creating a transaction and broadcasting it yourself, you'll instead be able to create the transaction and wrap it up with some other information like a message to the receiver, and then you send this whole thing to the receiver directly (like by submitting it to their website). The receiver then has the choice whether to accept the payment in which case he broadcasts it himself, or declines the payment, either way sending you a reply to tell you whether it's accepted or declined and additionally a message.

I don't see how this provides any more privacy than Alice simply creating a new address herself for each transaction. The difference being that your scheme allows for Bob to send without contacting Alice to get a fresh address, but what's the use case where you send coins to someone you've never contacted?

There is also the trust issue - if Alice doesn't really care about your privacy she might spend some of her coins together, associating her various blinded addresses with each other. Your payment links your address with an address which now is seen to be belonging to Alice, defeating the whole purpose.

Yes - in fact they must be, and all others must not be coinbase.

Actually that page is fairly detailed on what constitutes valid and invalid transactions and blocks. for example:


Not really, your attacker still has to craft a whole fake block for you which must pass the current proof-of-work - this is exactly as hard as creating a legitimate block. Additionally, if you are connected to more than one node, then the other nodes are going to be telling you about new blocks much faster, and the fake one you got is going to be orphaned. So the result is that an attacker has to give up what would be a 25BTC reward for solving a block in exchange for a window of a few minutes where he may be able to take advantage of a double spend against me.


This is a nice idea, but in practice you end up creating a DoS vulnerability: if I create an invalid transaction on purpose and send it to you, then you determine it is invalid and rush to announce the fact to the rest of the network, spamming everyone with an invalid transaction. The current way this is handled is that you determine my transaction is invalid and ban me for 24 hours. The rest of the network never have to hear about my transaction at all. The other problem is that you have to perform the attached proof in order to accept it, which results in the same amount of work as if you'd just performed the verification yourself, but with a lot more network traffic.

Use https.

People tend not to want to murder others or be murdered themselves, yet it still happens and we have laws to prevent / discourage it.


You're working under the assumptions that everyone mining coins want what's best for Bitcoin / care about Bitcoin's future, and all miners are equal - they are not, some will realize that producing large blocks that others can't handle is very much in their interest. Others may have the aim of just causing as many problems as possible because Bitcoin is a threat to them in some way, who knows? All you're doing is creating a vulnerability and expecting no-one to take advantage.

We aren't all hippies living on a fucking rainbow - problems don't just fix themselves because in your one-dimensional view of the world you can't imagine anyone not acting rationally and for the greater good.

Save a local copy?

I really don't understand this sentiment, especially from one of the devs. I think that everyone who complains that it's too difficult have just not bothered to find out how anything works.
In fact, I think it speaks volumes about those complaining that every one of these threads talk about a 'protocol spec', when in fact the way that the network passes messages is largely irrelevant to the working of Bitcoin (aside from the fact that it's very well documented and simple). The only important part is the binary format of transactions and blocks, so that you can verify proof-of-work and merkle roots, other than that it really doesn't matter how you obtain them - you could get all the data you need from blockexplorer.com and bypass having to connect to the network at all if you really wanted to.

There's only one thing you actually need to worry about - block validation, which is explained here. If it's too much to implement in one go, start with SPV style checks and work your way up, it's better to accept bad blocks than to reject good ones. Just don't mine or relay blocks until you're sure you've got verification completed, or isolate yourself from the rest of the network by connecting to a single trusted reference client node.

There's also the question of why you actually want to implement a fully verifying node. The only reason I can think of is if you want to mine with it - so you don't waste your effort producing invalid blocks. Other than that, you can get all the functionality you need from SPV checks and a full blockchain (making sure to verify the merkle root) for significantly less development effort, less cpu+ram use, less likelihood of forking yourself into oblivion, for a tiny reduction in security.

Additionally, there is almost zero financial incentive for creating an alternative implementation - no-one will trust it if it's not open source, and no-one will buy it if it is open source.

The biggest problems in creating an alternative client are software engineering type problems, not implementing the network protocol. How do you guarantee database consistency or recover from corruption if the power goes out while you're processing a block? How do you deal with re-orgs? How do you store your blocks/headers for best performance? How do you minimize the expensive processing you perform on bad data before you realize it's bad? How do you properly deal with errors like failed verification or your DB crapping out so that you don't confuse one with the other and end up stuck on a fork? If you receive an invalid block a number of times from different peers, when do you decide that either you're under attack or maybe you're rejecting a block that's actually good, and what do you do? Etc.
I think people are just scared of having to deal with network sockets and processing binary data, if everything was dealt with as JSON there'd be no complaints (other than network usage).

Are you trying to DoS bitcoincharts.com? Wtf does that link have to do with creating a wallet?

Yea, I was just coming back to mention that those release notes were from 7 years ago lol

Possible cause?

http://www.bouncycastle.org/releasenotes.html

Yes, once you have your elliptic curve code, you just multiply your private key by the generator point of the elliptic curve. The public key is then simply 0x04 followed by the x and y coordinates, 32 bytes for each.

Oh, sorry I missed that.

Anyway, bitcoind won't tell you what the error is directly, but it will be in the debug log.