Bitcoin on Freenet (BtcFn) Specification

There is a diagram but forum does not allow to post it (filesize).

See also freenet page. Freenet install is 3 minutes.
USK@oG7cGoUEBuHyulWpcmqV0yc-I569Re2A7RRs8zRljEs,IWIcXczmLdP9FEjTvoxJgGnXnK5~PxOppN-wYSADPWQ,AQACAAE/bitcoin-over-freenet/1/spec1.txt
http://127.0.0.1:8888/freenet:USK@oG7cGoUEBuHyulWpcmqV0yc-I569Re2A7RRs8zRljEs,IWIcXczmLdP9FEjTvoxJgGnXnK5~PxOppN-wYSADPWQ,AQACAAE/bitcoin-over-freenet/1/spec1.txt

Bitcoin over Freenet ("bitcoin-over-freenet" or "BtcFn")
Protocol version 1.0 (DRAFT), RFD #1

BtcFn project research (draft/specyfication) is sponsored by <da2ce7> (IRC freeNODE), thank you.
Draft, this specyfication, freesite&diagrams - <xelister> (IRC freeNODE).
Released on BSD license (C) 2011.

This document proposes how to use crypto distributed currency "BitCoin" in more anonymous(*) and un-blokable way - by transporting bitcoin communication not over normal TCP/IP, but over Freenet (secure distributed-crypto storage system).

(*) to have anonimity YOU MUST HAVE SEPARATE "CLEAN" installation of bitcoin, with CLEAN WALLET never used in not-anonimized way, or the criminals and enemies may poison your wallet with known to them transactions-coins and track you later.
Details are described: http://www.bitcoin.org/wiki/doku.php?id=anonymity <-- if you do ALL THIS, AND USE SECURE TRANSPORT (like btc-fn, or bitcoin over TOR), only then you will be quite anonymous.

*** Section 4 is most interesting overview of proposed transport format. ***
Skip 1-3 if you already know freenet and bitcoin.

1. Introduction to BitCoin - from network transport view.
2. Bitcoin over Freenet - Goals
3. Two-minute introduction to freenet - data storing

4. BtcFn - the format of transport <-----------
5. BtcFn - more details of format
6. BtcFn - kludges and details
6.a) Blocks inserts AND .PACK packing
6.b) Transcations inserts and naming
6.c) Friends, seeding and scoring
7. Meta tunnels
8. Ideas for actuall implementation

Installing freenet takes nowdays 3 minutes - go to http://freenetproject.org/ install it, and done. #freenet at irc.freenode.org for help (<toad> is main devel, ops are trusted).
Opensource java program. Sources in Git.
Our freenet page: http://127.0.0.1:8888/freenet:USK@oG7cGoUEBuHyulWpcmqV0yc-I569Re2A7RRs8zRljEs,IWIcXczmLdP9FEjTvoxJgGnXnK5~PxOppN-wYSADPWQ,AQACAAE/bitcoin-over-freenet/0/

------------------------------------------------------------------------------------------------------------
1. Introduction to BitCoin from network transport view.

Bitcoin <http://bitcoin.org> is a p2p network where each ~10 minutes someone solves and publishes a Block - strongly crypto signed data that lists who pays to whom how much of money 'bitcoin' virtual currency.
Everyone downloads all blocks to see what are the payments. It is pseudoanonymous (random bitcoin-addresses / IDs for each transcation, but neighbour nodes see IPs).
It can be secured more by protecting the transport.
If transport is fully secured (ISP etc can not tie bitcoin messagess passing network to any IP), and person does not connect to real life (e.g. order 100 "Yankees Suck" T-Shirts to his home),
and if this is done for ALL TRANSACTIONS EVER done by given bitcoin user (bitcoin wallet / bitcoin installation) from start, then such person should be trully anonymous against internet-traffic related demasking.

So in BitCoin we have 2 typese of basic data to transport:

BLOCKs: sent "1 to N" (1 publisher, many downloaders), long-lived, packets of 1-4 KiB data - called "Blocks" - that everyone must always download (and keep on disk), that are forever revelant
TXs: sent "N to N" (many publishers, many downloaders), short-lived, packets of ~1 KiB data - called "Transactions" - that only some users will need to download, and that are only revelant for few hours usually

In normal TCP/IP actually each data is shared as 2 messages (communications): a request for some data, and then message with reply with given data.
In Freenet instead we will present all the data under an USK@ "webpage" (freesite) so that everyone can download it. Big data in CHK@ and listed keys. This will be fast, anonymous(*), and uncensorable.

Some details:
*** Blocks: For bitcoin to work, we need to have "Block Chain" - that is a list of blocks;
Each block is a list of all transactions recently done and is very heavly-securely crytop signed.
New block is generated each ~10 minutes. Each block generated is one "iteration" of network: it confirms done transactions, and it rewards random participant of the network with 50 BTC (around 50 USD in Feb.2011) bonus to their account.
The more someone helps by generating new block, the more likelly he is to get the reward.
This generation of blocks is called Mining.
Sometimes the block chain can split: when two people generate their version of new block, for some time there can exist 2 (or more) versions of given block. Later the block that is more popular is preserved (the block on which more later blocks are based)
This choosing usually takes no longer then 2-5 generations. And 120 generations (= usually 12 hours) is considered absolutelly safe limit.
Therefore, all blocks older then 120 geneartions can be considered immutable - so can be nicelly packed into bigger packs and be all downloaded in same version (packed to same CHK@ key) by everyone.
For very young (newest) blocks, for first few minutes or even hour after geneartion, there can be multiply versions/candidates for block number 100500 in example (generated by other computers).
Receiving blocks is important to allow to receive payments.
Inserting blocks is needed for the receiving to work, as well as it could be used for anonymous mining (but here it is important to have low lag, best <30 sec or even lower, otherwise bigger chance your block will be too late inserted into network and other blocks in chain split will win with it, discarding it)

*** Transactions: Orders to "make a transacation" are small, easly signed by pubkey informations.
They are sort of like small notes "I, id=foo, pay to some address id=bar, 20 BTC, on day 2011.01.01", and are signed by the person that pays.
This small notes easly fly around the network, and are later listed in the generated blocks.
Inserting transactions is important for making payments (and for receiving transactions)
Receiving transactions is important for mining (although, probably mining would work even without that).

(*) to have anonimity - [was explained in previous chapter]

------------------------------------------------------------------------------------------------------------
2. Goals:

As discussed above, we need TX and BLOCKs. They are needed for following operations:

To just send bitcoins (pay) ---> you need to: insert TXs
To just receive bitcoins --> you need to: download BLOCKs
To mine blocks ---> you need to: download TXs, download BLOCKs, insert BLOCKs - all with low latency (this can be hard on freenet, but possible)

Gateways to connect freenet-hidden nodes of bitcoin to normal bitcoin users that use TCP/IP need to do all:
receive BLOCKs from TCP, and from Freenet
receive TXs from TCP, and from Freenet
send BLOCKs to TCP, and to Freenet
send TXs to TCP, and to Freenet

Therefore we propose to write a full freenet<->bitcoin node, that can run only in freenet, or connect freenet<->normal-bitcoin.
Lets call it "BtcFn" (bitcoin over freenet).

If this program runs in fn-only mode, then you can do all tasks, and if you run in gateway-mode, then you are helping others (the fn-only nodes) to reach main bitcoin network.

Running gateway-mode should be more secure actually, because you can intermix the things you push with with normal network with your own inserts (your own transactions and blocks) more naturally.
Unless you would like to keep in privacy fact that you do run a bitcoin at all on this computer.

------------------------------------------------------------------------------------------------------------
3. Two-minute introduction to freenet - data storing

Introduction to freenet: each freenet-node is client&server at once that can download/upload and host-store the data. Data is static. Data can be anything (html pages, music, images, programs, messages, chats, etc).
All data is hosted distributed on any of computers in network, but it is stored on such computers in a way that even this computers can NOT read this data.
To read data you need a speciall URL that identifies the data by hash PLUS has a secret password.
If Bob inserts file say "freedom.pdf" into freenet, it is cut into small parts and end up in example on Alice, Celine and Daniel computers, and Bob knows the "URL" (key).
Alice has part of some file stored, but can not open it (no password).
Bob gives the url-password (the key) to Frank. Frank can now ask computers "who has part of file with hash ...", and he will get the part from Alice Celine and Daniel, put it togeateher and decrypt it.
This gives plausible deniability to people holding data parts. (This is a simplication, e.g. there are more levels of encryption, and redundancy).

All pages, data, messages are static. There is no centrall server. There is no communication to server of website, just the website (or data) is distributed-mirrored in many computers. (so this is NOT as Tor or I2P).
Freenet is almost impossible to censore, as there is NO CENTRAL SERVER even for given web page! So it can not be shut down like hidden .onion page.
(But the cost is that there is no server-side, just static HTML pages and static data usually).
You would have to find the person that inserts (uploads) updates to given page. This is harder because Freenet gives anonimity to some degree. EVEN if you would find and kill him, still old version remains on few computers + few caches if the page was popular.
Even if you would force the author to update the page to an empty version, still old version remains and can be accessed for some times (usually months, or year, or years if it is from time to time downloaded by someone).

IMPORTANT:
1) There is caching of popular content - the more a file is popular the faster it works!! (reverse of typical situation on normal internet - too popular site is overloaded/DDoSed and slows down)
2) You can have the url-keys as CHK@, SSK@ , USK@ or KSK@.
CHK@ "static files" - address is the same for same file, no matter who uploads it. So it is good for popular files. There is no "owner" of the file.
USK@ "updatable website with owner" - is like a web site that you can update by uploading new versions. There is a public address + secret key. Owner of secret key is the owner of the file only he can upload file to this address. He can update the file by releasing a new version (old version remains). New version will be after a while puicked up by other clients observing this USK@ address.
Address is different for different site owner.
SSK@ is simmilar to USK@
KSK@ "updatable simple webiste with no owner" - is a simple short address - everyone can insert "into it". Example address: KSK@foobar. Owner: anyone - if few people insert different file to address KSK@fooar then they can sort of "fight" about who's version will be there. KSK@ can be spammed.

Typical time to insert few KiB file is 1-5 minutes. Download: if file is old or not popular then download can take 1 minute to few hours. If file is popular then usually <1 minute.
Downloading new versions of USK@ is similar to normal downloads.
You should download not more then 50-100 files at once best.

------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------
Moving to the actuall BtcFn Bitcoin-Over-Freenet cool stuff.

------------------------------------------------------------------------------------------------------------
4. BtcFn - the format of transport <-----------

Reference of normal bitcoin protocol: https://en.bitcoin.it/wiki/Protocol_specification

Each BtcFn-Node will get information from observing normal TCP/IP part of bitcoin traffic, and will present this on freenet page (USK@ page + CHK@ files for bigger data like packed series of blocks).
Each BtcFn-Node can also observe other BtcFn-Node pages by pooling or waiting for updates of their USK@ pages and downloading linked files (CHK@ files), therefore getting blocks and even transactions published secretly by other Bitcoin-Over-Freenet nodes, and passing this information back to main TCP/IP bitcoin network, therefore allowing full both-ways connectivity.

Peers in BtcFn: your node must know USK@ addresses of other BtcFn nodes, and must publish self to other nodes, to work correctly.
Nodes will publish known friends references. Initiall nodes will be hardcoded into client. More can be manually added by admins (e.g. from friends).
Freenet seeding: nodes can also possibly paste their references into Flip Freenet-IRC and/or into Frost boards and/or FMS boards.
Bitcoin seeding: upon seeing a received payment to my wallet with label "BtcFn peer me: USK@.........." good node should start observing given node.
Details explained below.

Each BtcFn-Node will have one identity - an USK@ keypair. It will store the private key locally (e.g. harddrive) and should publish the publick USK@ address so others can see it.
Node can have a nickname, but the long USK address that is a form of public key is what needs to be stored and trusted.
Lets say our example node will have nickname asmith and USK address of USK@XYZ123...

BtcFn-Node will publish and regulary update a site (html-like, but practically a text file with easy line by line parsing).

This file will give information:
node name, format etc.
All the blocks - in form of "freenet-URLs" (CHK@ keys) of the keys. Old keys will be packed, e.g. as 10,000 keys at once, so that old keys are faster downloaded.
Latest 20 blocks will be alwyas unpacked and referenced by hash rather then by number, because there can be a block split in progress (e.g. many proposed versions of block nr. 12345 and we may want to present them all to allow our clients to decide which block to use)

The transactions - will be pasted inline and Base64 encoded. If there are over 100 transactions to be presented, then most of them should be moved to separate CHK@ key or keys (and possibly packed togeather).
Good BtcFn-Node will inline-present most valuable transactions (sorted by "TX fee") and move others to separate file.

BtcFn-Node will publish and update following USK page (website / freepage):

USK@XYZ123....../btcfn-asmith/index.html

------------------------------------------------------------------------------------------------------------
5. BtcFn - more details of format

USK@XYZ123....../btcfn-asmith/index.html
Index.html is following file, saved as ASCII text (or other one-byte encoding) with unix (\n) end of lines.
In this example text in { } is the name of the variable, followed by example value
i
Note: Almost all integers are encoded in little endian. (same as in bitcoin protocol)
Again - reference of normal bitcoin protocol: https://en.bitcoin.it/wiki/Protocol_specification

UUEncode1 here means: http://en.wikipedia.org/wiki/Base64 in variant RFC 2045, except, the '/' characters will be replaced with '-' character,
and with the first line (header) skipped.

BtcFn-Node node is a program that will implement format&rules described here.

Each BtcFn-Node will have one identity - an USK@ keypair. It will store the private key locally (e.g. harddrive) and should publish the publick USK@ address so others can see it.
BtcFn-Node will have list of friends - other BtcFn-Node nodes, as list of USK@ keys + time added + trust level.
BtcFn-Node can have a nickname, but the long USK address that is a form of public key is what needs to be stored and trusted.
Lets say our example node will have nickname asmith and USK address of USK@XYZ123...

BtcFn-Node will publish and update following USK page (website / freepage):

Freenet works best when downloading no more then say 30 files at once in normal conditions.

USK@XYZ123....../btcfn-asmith/index.html

Index.html is following file, saved as ASCII text (or other one-byte encoding) with unix (\n) end of lines.
In this example text in { } is the name of the variable, followed by example value

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>data</title></head><body><pre>

[btcfn]
{BtcFn protocol version as integer}1
{BtcFn protocol oldest version that you should use to talk to us}1

[node]
{This node nickname or word 'anonymous'}asmith
{this node USK address}USK@XYZ123....../btcfn-asmith/

[message]
{Some MOTD or message or information from this node operator - few lines of teext}
Hello all!
Node moved to better server.

[contact]
{Some contact informations - few lines of text}
E-mail:jsmirhjr@gmail.com
Freemail:jsmithjr@sdkad3r232.freemail

[block-keys]
{CHK key}CHK@vzy2.../btcfn-block-0.bin
{CHK key}CHK@xzw..../btcfn-block-1-10.pack.bin
{CHK key}CHK@gz3..../btcfn-block-11-20.pack.bin
{CHK key}CHK@b3y..../btcfn-block-21-30.pack.bin
{CHK key}CHK@nd3..../btcfn-block-31-40.pack.bin
{...}
{CHK key}CHK@nds..../btcfn-block-101-200.pack.bin
{CHK key}CHK@nuh..../btcfn-block-201-300.pack.bin
{...}
{CHK key}CHK@gr2..../btcfn-block-101021-101030.pack.bin
{CHK key}CHK@c2f..../btcfn-block-101031.bin
{CHK key}CHK@cd2..../btcfn-block-101032.bin

[friends-usk]
{age days}10 {lag}30 {valid}100 {complete}90 {personal}50 {friend USK@}USK@fj2d.../btcfn-bob/
{age days}3 {lag}30 {valid}100 {complete}60 {personal}-50 {friend USK@}USK@vhh7.../btcfn-carl/

[payments]
donate: 0.01 , 1uzNqi5dnYZFTEv3kHFdnjbij1M3e1MKz
peerme: 0.05 , 1MeJsZrm9c3Bi948KkaqcJDQjASmTC9tsj <-- this will make node observe payer
seedme: 0.20 , 12GqQ5bQe8VQvthwrUDmTEoVzC2a53VUSN <-- this will make node publish payer with neutral personal-trust

[tx-inline]
hash: {hash of transaction}
txfee: {tx fee of transaction as float with dot, good node should present this information, or write -1 if unknown}
data:
{UUEncode1 of transaction}

{Now the example of above, in example 3 transactions inlined:}

hash: 8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87
txfee: 0.05
data:
hvIVk0tV4P1i/rTW2g/C7emYUHovLaq5RI5Oe2EvGkmdr2nQo1USHRrfVAa2
ugDTvPuVK8E98jWjFfUE00nnHalQDRn35P9sZLF4yOgpb6WFPmycJbYxITwO
HGNS3LNV0clG40/P7VKfS112oDZ/F89EJJeIZGuy5NCIQIlll63JoPBpQ2jE
jNouxPrrwZYrjSZ347Ht4twM2fQeIecZLrCKa+N1+YK7f1lZB0cs878iJiOX
5edUOLOmGMHfiHLACKElVt3RLZca
====

hash: d6c7cb254aa7a5fd446e8b48c307890a2d4e426da8ad2e1191cc1d8bbe0677d7
txfee: 0.04
data:
FH4CGkdJIiQmFICBDbazXHjy/qrBBJ0uenVjH0+6ZsYAREAyGyEsRXBlT5+A
gJM0/NA9zHZvy4W+/joTkhfvwV7qo23O6nwz8my6XPd1ESZ3PAu0IRNTdTNj
uwTS+Nckva28B3VkGuNSUGpwWQGBTathK6mVrRX3PPHcmmiCEGUVYQ1glsWr
O4+bNw==
====

hash: fbde5d03b027d2b9ba4cf5d4fecab9a99864df2637b25ea4cbcb1796ff6550ca
txfee: 0.04
data:
tWwcXKtbKWMM2Z3o6hxna/52GLAYbvBrdaLfNFvdqofO1FZEcYr/gCxjTDvv
8Sx/Q1iHLw9Ma17Uv22tp9cRGIOr36vQaYDxI2pvgpG3GwsWz91Z0QrWou6S
AyeIYgX9uIYFWarYt+xXEwB4hmDN/iQ88wp4m2+ZRXDPAcKpc5XkQNp8uyNV
ZBxCtt4TN+gsYV2vjAwrpETmts8PJyxJbnEmrBaJRQWQHQQ7a74VXfDunWDi
TB2AqzVIaBlL
====

{perhaps 47 more TXes, so that we can demonstrate tx-keys - transactions that where moved to separate keys}

[tx-keys]
{CHK@ of a .bin of tx or .pack.bin with given tx-fee}CHK@f2s2/btcfn-tx-0.02-0.06.pack.bin
{CHK@ of a .bin of tx or .pack.bin with given tx-fee}CHK@f2s2/btcfn-tx-0.01-0.02.pack.bin
{CHK@ of a .bin of tx or .pack.bin with given tx-fee}CHK@f2s2/btcfn-tx-0.00-0.0009.pack.bin

[end]
</pre></body></html>

All data between [btcfn] and [end] is interpreted, while other data ignored.
All markers [..] begin on line (no white spaces) and no trailing white spaces.

------------------------------------------------------------------------------------------------------------
6. BtcFn - kludges and details

------------------------------------------
6.a) Blocks inserts AND .PACK packing

Details of blocks inserts.
Single Block, or a Pack of many blocks, are inserted as a file into freenet, to a CHK@ key.
Files inserted by anyone end up as same CHK@ , and everyone downloads same CHK@s so they should be very healthy (popular files) so should work very well (fast downloads etc).

BtcFn-Node should upload once (and periodically re-upload a bit) files with blocks.
Individual block will be inserted as:

1) single block:
btcfn-block-00000000000201905fdc60d46e74ad3adeaae6ced8f4c64b2036ceb5e0a0d0cc.bin
(example: http://blockexplorer.com/rawblock/00000000000201905fdc60d46e74ad3adeaae6ced8f4c64b2036ceb5e0a0d0cc)
the file will have the binary data of the block, as would be sent in "block message" of bitcoin protocol specyfication.

2) multiply blocks:
the file will have the binary data of the block, in following format:
<size1><data, data, data .... data><size2><data, data, data .... data><size3><data, data, data .... data> ...
so:
size = 4 octetcs (little-indian integer) telling how long is the next of data (how many octets)
data = octets of the data (in same format as used on transport level inside bitcoind), as would be sent in "block message"
size == 0 is marking end of file and is always present at end.

file with multiply blocks is named as:
btcfn-block-1000-2000.pack.bin
btcfn-block-2000-3000.pack.bin
btcfn-block-3000-4000.pack.bin

generally:
btcfn-block-START-END.pack.bin
where length (END-START) is 10^n (n=1..5) so lenght can be 10 or 100 or 1,000 or 10,000 or 100,000,
and START%length == 1,
also in given itme as many blocks should be packed as possible to generated smallest amount of files, eg:

for 33 blocks use packs: 0, 1-10, 11-20, 21-30, 31, 32, 33
for 101 blocks use packs: 0, 1-10, 11-20, 21-30, 31-40, 41-50, 51-60, 61-70, 71-80, 81-90, 91-100, 101
for 103 blocks use packs: 0, 1-100, 102, 103
for 301 blocks use packs: 0, 1-100, 101-200, 201-300, 301
for 2144 blocks use packs: 0, 1-1000, 1001-2000, 2001-2100, 2101-2110, 2111-2120, 2121-2130, 2131-2140, 2141, 2142, 2143, 2144

for ~200,000 blocks (this numbe will be reached in late 2012 year) in wors case we need to download:
for 199999 blocks: 0, 2(x100,000), 9(x10,000), 9(x1,000), 9(x100), 9(x10) and 9 single files = less then 50 files, which is tollerable load on our freenode node, even when downloaded at once.

------------------------------------------
6.b) Transcations inserts and naming

Details for transactions:
Transactions are packed into .pack.bin in same format as Blocks, but other filenames;
Good node should decode transactiosn, understand txfees, and pack them sorted by txfees, so that e.g. under huge tx spam miner client could decide to download only .pack.bin with transactions worth at least >= 0.03

Filename:
btcfn-tx-{txfeemin}-{txfeemax}.pack.bin
this should hold PACKed all outstanding transactions known to BtcFn-Node whith given txfee transaction fee values between (>= <=) txfeemin..txfeemax

txfee will be string of a float number, with dot '.' for decimal point, with precission enough to present the number fully (truncated to precision 10 digits).
(As of time of writting, 0.01 BTC is standard txfee, and 0.00 BTC).
Txfee should symbolize how many BTC miner can earn from processing given fee - this is the goal of this information in file name, so miner under epic tx spam could decide to care about only some TXes do download.

------------------------------------------
6.c) Friends, seeding and scoring

Format for publishing list of friends is:

[friends-usk]
{age days}10 {lag}30 {valid}100 {complete}90 {personal}50 {friend USK@}USK@fj2d.../btcfn-bob/

lets explain this variables:

{age days} integer, granulity=1, values 2..100 - when we first seen (successfully downloaded USK) this ident
{lag} integer, granulity=30, values 2..300 - how many minutes we think it takes this node to fully publish the data (including time it takes us to download)
{valid} integer, granulity=10, values 0..100 - how much of the provided data we estimate as correct.
   If any of records are invalid (not correct on transport level or as bitcoin data, or not valid bitcoin data etc, that publisher should had filtered and not publish because it is garbage) then we lower score.
   At least -25%..-50% if any TX is bad and -25%..-50% if any block.
   At most 25 (or just 0) if node is presenting partially invalid format/syntax.

{complete}integer, granulity=5, values 5..95 - how big part of all data existing actually is reported by node.
We can know number of actually existing blocks easly. 0..50% score for referencing all blocks correctly.
We can estimate number of transactions that should be known by now (e.g. by ovserving other nodes, and by observing TCP). We take into account node lag. If node doesnt publish some TX that we know existed at
least 10 seconds before time of publishing the USK page, then we penalize by -25..-50%.

{personal}50, granulity=25%, values -100..100 - how much we personally like or dislike. Rules:
    0 is neutral node learned by some bootstraping
    25 or 50 is by more advanced bootstraping (e.g. FMS) that is rather resistant to blind spam. Recommened 50% if someone donated us ("seedme" / "peerme" bitcoin transaction was made by node owner to verify himself)
    75 if we know it a bit more (personally checked best)
    100 if we trust it almost ultimatelly
    -25..-50 if we suspect node may be spamming, or other nodes we like set it to lowe score
    -75 if we think it is spammer or some adversary in some way or should be banned
    -100 if we are sure it should be banned
{friend USK@} the USK address of node. like: USK@fj2d.../btcfn-bob/

So, our BtcFn node may publish Bitcoin addresses so that other BtcFn operators can pay us a bit to verify themselves. This is done in section:

[payments]
donate: 0.01 , 1uzNqi5dnYZFTEv3kHFdnjbij1M3e1MKz
peerme: 0.05 , 1MeJsZrm9c3Bi948KkaqcJDQjASmTC9tsj <-- this will make node observe payer
seedme: 0.20 , 12GqQ5bQe8VQvthwrUDmTEoVzC2a53VUSN <-- this will make node publish payer with neutral personal-trust

Each of this commands include what node say must be the payment.
If our BtcFn-Node receives in fact such payment to this address, then they will act as the payer says basing on reading the label;
For donate - nothing probably.
For peerme - node should start observing&pooling USK@ address given as label (first word of label, trimmed from whitespaces if any)
For seedme - node should act like for peerme plus list the USK@ address (given as in peerme) on their Friends references [friends-usk]

------------------------------------------------------------------------------------------------------------
7. Meta tunnels

A general idea to make things really TOTALLY secure. Or paranoid. We let you decide

But freedom is shurly in danger in many parts of todays world, so...

Freenet is quite secure (many say that more then TOR, and definatelly more unblockable e.g. by country wide firewall like in China).
But freenet is not perfect.
You can improve security by connecting your BtcFn to only few trusted IRL friends.
But still there is room for improvment.
If you pump lots of data in/out of your node, your peers in freenet network can notice the all parts of USK page of Btcfn node "asmith" are comming from IP of your friend #1 or #2 or #3, and eventually debug (e.g. ISP level) who this guys connect to. And if any of your friends turns on you - even worse.
In some countres any type of capitalistic activity like that or taking normal things like trade and money in own hands, could rsult even in death even without strong evidence "just to be sure". Or at leat lead to attack by some criminals or give away your privacy.

Idea to counter this could be to not publish information by your USK node that is readable by everyone.
Instead publish information that only BtcFn node A and B can read.
Or even better, make information that only node A can read enought to get information encrpted for B, then he sends that to B and B decrypts.

X --- tx order crypted to A:B ---> A ---- tx order crypted to B ---> B <--- ovserved by other BtcFn nodes P,Q,R ---> TCP/IP network <-- other bitcoin users

Yes, this is like TOR. Or generally garlic routing. Except, we can make long long chains since we dont care a bout latency and TCP timeouts.

Now only way to know that actually you made this transaction, is really hard. Attacker would need to controll computer of A *and* of node *B*.

Make longer chain, add long padding-delays.. chain A:B:C:D:B:D:C:F:G:H:A:C with 5 h delay on each step.
This is a seed of a meta tunnels idea. Use inline openpgp, and each node would publish own pubkeys.
Perhaps this would be implemented one day.
You could send such meta-tunneled messages to yourself too, to see if nodes are working with tunneling and are they doing all fine (e.g. actually delaying on hops).
You could send same order via few tunnels and/or make tunnels branch to give redundancy if one node would die during transport to not restart from scratch.
Perahsp some peyment could be incorporated into each hop to convince BtcFn node operators more to support this idea and limit spam.

In such super paranoid mode, your tx would be executed days later, but I doubt anyone in the world could know that you actually ordered this and this is "your 'money'".
(Of course follow other Anonimity advices as listed before).

------------------------------------------------------------------------------------------------------------
8. Ideas for actuall implementation

Start with just some ideas

This specyfication aims to cover needs for upcoming year (therefore anti spam trust system in seeding and meta-tunels).

Implement in steps.

Hook into bitcoind on receiving data to publish it and add RPC call to inject new TX and Blocks.
Make the deamon of node as java program calling freenet node via API, or as freenet plugin even?

Start bounty to get it implemented?

Sounds like 3-4 weeks to make it really work + debugging and fixes.
A bit more to have mining working well. +2-4 weeks for meta-tunnels.

And then up to x4 more time if more polishing, even more security, or new feautures would be needed Wink

Talk to me on jabber: xelist@jabber.org or irc.freeNODE.org #bitcoin-dev or #freenet (if Im not bussy Wink

,
thanks.