Yes, the specification is being worked on

First let me say, quoting my friend, this is a wonderful idea, because freenet is PERFECT for anonymous distribution of such stuff, especially the blocks chain,
in freenet, opposing to Tor, I2P, and normal internet, the more given content is requested, the FASTER it works
This is mainly why we taken this bounty 


Now pondering few ideas, also asking friends (and they know guys in freenet community better).

-------------

So far - for discussion:

we want to have freenet-hidden-BC-node, lets call it FN-BC.
Such nodes can use freenet instead of any other TCP/UDP/IP to communicate with main bitcoin network.
FN-BC nodes can be used to:
1) FN-BC-TX - send transactions (to bitcoinaddress, not to IP). This is easiest, just implement SENDING "tx".
Usable if you have a wallet with coins (BUT, wallet would make you tracable to tie which IP generated given block?) and you want more anonymous way to pay someone, and you do not trust open-internet not TOR.
2) FN-BC-BK - get blocks - to receive transactions, view status of network, current diff/block number/ and so on.
Usable to have basically full client (without some misc commands like paying to IP probably)
3) FN-BC-MINE - miner node - can generate blocks. Well mining is bound to be less successful - high latency. But should be possible.
4) FN-BC-GATE - gateway node - connects to both freenet-bitcoin network and main bitcoin network and passes messages between freenet world and TCP/IP based network of bitcoin nodes.


Which of this actually we need to implement now?
We want just to allow checking blocks/receiving, or just sending transactions or both?
Do we need to support mining/generating too?


-------------

Initial fast draft (thinking out loud too)

Important part would be to do it in a way that efficiently utilizes Freenet, while being resistant to both spam and censorship.



IP world ---> Freenet world

publish list of (chk links to) blocks
USK@.../bitcoin-to-freenet/block/
  CHK@c.../block-1
  CHK@k.../block-2
  CHK@x.../block-3
  CHK@y.../block-4
  CHK@b.../block-5
  [...]
  CHK@j.../block-100204
  CHK@a.../block-100205

publish list of (chk links to) transactions that are awaiting encoding into blocks (miners need that)
USK@.../bitcoin-to-freenet/tx/
  CHK@v.../tx-a828c0b
  CHK@v.../tx-f0bc02a

publish list of identities (USK@ addresses) of other to-freenet gateway nodes
USK@.../bitcoin-to-freenet/seed1/
  USK@... ; 1294167000 ; 1294561000 ; 0      (address; last-seen ;   optional info: first-seen ; trust -100..+100 float )
  USK@... ; 1294167000
  USK@... ; 1294167000 ; 1294561000

Publish list of identities (USK@ addresses) of other from-freenet gateway nodes, that are described below. Same format.

Above assumes that we have few root nodes (we must know at least one USK@ to start the process). It can be hard-coded or obtained from friends or freesites/websites etc.

Performance review:
As a result, say 5 "root" gateway nodes, plus 30 more gateway nodes found out by more-ref/, will insert 35 freesites USK@.
The 5 root node's freesites will download often - so they will be very popular (lower latency, reliable).
30 more freesites should be quite popular too.
And the CHK@ keys, will be VERY popular, since all 35 sites should reference same blocks (especially once they agree on main branch of blocks tree).

To avoid spam, e.g. bogus USK@ gatways that will insert references to some crap instead of bitcoin blocks, we can wait with download of CHK@ until it is referenced
by more then one node. A hand editable black/white list of trusted gateways should also help.

Or, instead, just use KSK@ board system (like Frost) which is far more simple - but is prone to be overloading with spam (as Frost is now).


Freenet world ---> IP world
- send out new transactions (-TX)
- possibly send out new blocks that where mined (by -MINE)
The rules here are similar.
We may want to change the USK@ identity more often.
And to avoid connecting our USK@ to given transation, or to connecting transactions togeather, such nodes should publish not their own transactions and new-blocks, but also rely each-other random transactions, while changing their identity USK@ from time to time;

Or, instead, just use KSK@ board system (like Frost) which is far more simple - but is prone to be overloading with spam (as Frost is now).


http://www.bitcoin.org/wiki/doku.php?id=network


This is early draft of the ideas.
Please discuss 
Before claiming the bounty, we should polish details, give examples and full details on individual "packets" format (e.g. simply the payload that would be normally sent to other node over TCP?)
and make adjustments if discussion here shows ways to improve the idea