Topic: Alternate methods of blockheader distribution (Read 1245 times)

I just learnt about this thread and tried the DNS method:


You said it was a test implementation so I'm not concerned it doesn't work for me, but you might be interested .

Oh i see, what about hosting this feed on an IRC since bitcoin already uses IRC to bootstrap?

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.

What is the advantage of using twitter or another server as opposed to just p2p? Wouldnt p2p be the most resilient, secure, accurate source for this?

It's not a bad idea, but my main motivation in creating this service was with regards to the idea that information is easy to spread and hard to stifle - blockheader data is self-authenticating for an SPV node.

At minimum I think you need to sign the block height, block hash, and current time. To save space, provide the RIPEMD160 hash of the 32byte blockhash. Compact signatures, such as produced by the signmessage functionality are 65 bytes. That gives us 20+4+4+65=97 bytes. With base64 encoding that's 97*4/3=124 bytes, creating the following 140 character tweet:


Patches welcome.

"Retep" does kinda have the same ring as "bernanke"…

More seriously, I know Retep has been working with trusted computing and remote attestation.  A quorum of trusted computing signers that securely talk to a great many nodes (need authenticated p2p and a WOT) and will never sign blocks that continue a fork that cuts back a previously existing chain valid chain by more than N blocks... would be pretty neat. Though its sort of outside the Bitcoin security model. You could even fidelity bond them, but fat lot of good that would do since the underlying currency where the bonds are would be destroyed by their defection in the event that it ever mattered.    Perhaps such a device with bitcoin fidelity bonds would be a good way of securing an altchain.

You should do this but also offer a digital signature on what you see as the highest block hash.

Your service could be used in a later 51% attack as manual input on what blocks to accept, if one ever happens.

Now someone needs to make a simple tool that checks twitter over tor and talks to bitcoind via RPC and sounds klaxons if twitter seems to be claiming a longer chain.

I got around to releasing the source code for the twitter thing: https://github.com/petertodd/blockheadertwit

Note the #btcblkhdr hashtag - I would be greatly amused if other people start running the bot with that same hashtag. Note that the twitter API allows you to search for recent tweets with a given hashtag...

Awesome - though currently I'm only getting responses with the same A record 67.215.66.132, not AAAA.

The fundamental security assumption of bitcoin is that information is easy to copy, and hard to censor. Thus there should exist multiple ways of distributing the information that comprises the blockchain to ensure that criteria is met. In particular blockheaders provide critical information about what chain the majority of hash power is working on, and themselves are self validating with some assumptions.

Thus I have developed two alternate blockheader distribution systems to be used in addition to the current p2p network.

The first, blockheaders via DNS. Headers are just eighty bytes, thus it takes just five 16 byte AAAA records to distribute one header. The advantage of using AAAA records is resistance to censorship: it can be expected that even most badly behaved DNS resolvers will pass AAAA records correctly. Equally AAAA records do not need special reaolvers, requiring just the standard gethostaddr() type calls supported by a plethora of languages.

DNS also has the advantage of built in caching to reduce the load on the central header server. A test implementation is available: blk(num)-(0-4).blkhdrs.bitcoin.petertodd.org It should be running in this auspicious day - if not I will give the server a kick later tonight. (I just crawled out of a cave in rural West Virginia)

The second method I have developed needs no explanation: http://twitter.com/blockheaders