Bitcoin Forum
March 28, 2024, 04:21:01 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Bitcoin on Freenet (BtcFn) Specification  (Read 15418 times)
da2ce7 (OP)
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
December 16, 2010, 10:32:26 AM
Last edit: May 07, 2011, 06:21:49 AM by da2ce7
 #1

Bitcoin on Freenet.

Draft Specification is out for comments! Draft on Freenet!

Talk about this project @ eng.bitcoin on freetalk!

Please post below about changes, features and possible attacks.


Development Bounty
Working implementation, in MIT style licence.

Looking for pledges!  We are about to commence the development stage, need to hire developers Smiley


Fund-raising thread:
https://www.bitcoin.org/smf/index.php?topic=7181.0

One off NP-Hard.
1711642861
Hero Member
*
Offline Offline

Posts: 1711642861

View Profile Personal Message (Offline)

Ignore
1711642861
Reply with quote  #2

1711642861
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711642861
Hero Member
*
Offline Offline

Posts: 1711642861

View Profile Personal Message (Offline)

Ignore
1711642861
Reply with quote  #2

1711642861
Report to moderator
1711642861
Hero Member
*
Offline Offline

Posts: 1711642861

View Profile Personal Message (Offline)

Ignore
1711642861
Reply with quote  #2

1711642861
Report to moderator
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 509


My avatar pic says it all


View Profile
December 16, 2010, 10:39:28 AM
 #2

Hey! That's a great idea! Smiley

The source code for FMS might be a good starting point.
grondilu
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
December 16, 2010, 10:42:34 AM
 #3

I'll add 100BTC for a working implementation.

I doubt it will be done any time soon, though.

da2ce7 (OP)
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
January 08, 2011, 08:31:15 AM
 #4

I kind bitcoiner has pledged to do the Bitcoin-freenet specification!  Grin  My Bitcoin wallet was getting too heavy anyway Tongue

One off NP-Hard.
grondilu
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
January 08, 2011, 03:17:18 PM
 #5

Hum, I've pledged 100 BTC for this.  Can I change my mind and cancel it ?

kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1014


View Profile
January 08, 2011, 04:12:52 PM
 #6

Isn't the bounty, 450 BTC?

da2ce7 (OP)
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
January 08, 2011, 11:12:39 PM
 #7

Hum, I've pledged 100 BTC for this.  Can I change my mind and cancel it ?


Sure Tongue  I'm sure that you will put that 100BTC to other good use!

One off NP-Hard.
grondilu
Legendary
*
Offline Offline

Activity: 1288
Merit: 1076


View Profile
January 08, 2011, 11:18:51 PM
 #8

Sure Tongue  I'm sure that you will put that 100BTC to other good use!

I will give something when this comes out.  But not 100 BTC.

johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
January 09, 2011, 08:48:07 AM
 #9

Broadcast the block chain over freenet.
Design it in a way that everyone inserts the same information, so that only clients that are only connected to freenet need to download the blocks via freenet.  Eveyone else acts as junctions between the normal net and the freenet.

I bounty 150BTC for a somebody to make a specification. (being worked on)  Grin

Yes, the specification is being worked on Smiley

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 Smiley
This is mainly why we taken this bounty  Smiley


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  Smiley
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 Smiley
sandos
Sr. Member
****
Offline Offline

Activity: 440
Merit: 250


#SWGT CERTIK Audited


View Profile
January 09, 2011, 11:49:53 AM
 #10

I know the freenet people are discussing various performance bottlenecks in regard to sone and maybe freetalk. I think the same principles might apply to this.

da2ce7 (OP)
Legendary
*
Offline Offline

Activity: 1222
Merit: 1016


Live and Let Live


View Profile
January 09, 2011, 11:35:29 PM
 #11

Each CHK@... could contain only the raw block data.   Blocks are listed in 10^2 tables.


Code:
CHK@... -> list of 100000 CHK's with blocks 0 to 99999

CHK@... -> list of 1000 CHK's with blocks 100000 to 100999

CHK@... -> list of 100 CHK's with blocks 101000 to 101099
CHK@... -> list of 100 CHK's with blocks 101100 to 101199
---
CHK@... -> list of 100 CHK's with blocks 101700 to 101799

CHK@... -> list of 10 CHK's with blocks 101800 to 101809
....

When the lists get moved into a bigger group, the old groups can be forgotten.  Each list references the previous list.
The CHK@ addresses for the Block Lists, should be reliability computable from having the block chain. Like the block CHK@ addresses.

To obtain the latest 10 block addresses, use FMS or something like that.

Maybe use darknet messaging to send new transactions, to be included in the block chain... or maybe FMS.  (this is the tricky part)

One off NP-Hard.
johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
February 14, 2011, 07:12:10 PM
 #12

Hello,
freenet was heaving some delays and problems with USK@ pooling, now this is close to fully resolving.

Well this should not stop any implementation.

Stay tuned for update today
johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
February 16, 2011, 08:53:07 AM
 #13

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 Smiley 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 Smiley 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? Smiley 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.




johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
February 16, 2011, 02:54:30 PM
 #14


http://imagebin.org/138208

Anonymous
Guest

February 17, 2011, 02:09:48 AM
 #15

50btc for a working implementation.    Smiley
johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
February 17, 2011, 02:53:41 AM
 #16

50btc for a working implementation.    Smiley

Thank you Smiley

We estimate it should be 2-4 weeks to implement most of this stuff (except for complex auto-trust, just normal trust + payed trust).

Best 1000 - 2000 BTC to do it really.
More to do all the fancy/paranoid ideas as well. This messages will be carrying most USD/KiB worht Wink so make sense to super-secure it, but perhaps later in next iteration/bounty.
gohan
Jr. Member
*
Offline Offline

Activity: 52
Merit: 1


View Profile
February 18, 2011, 02:53:24 AM
 #17

Add another 50 BTC from me (wish I had more to spare). When transactions can (potentially) cross in/out Freenet, I'll consider it a working implementation. However I'm guessing we'll also need a lot of testers to actually get this working, that's why I said potentially, so I'll pay it anyway when everyone here is content with the implementation.

A naive question (haven't read the draft thoroughly): What happens if there aren't an adequate number of gateways? Wouldn't it cause the network to split?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5152
Merit: 12580


View Profile
February 18, 2011, 03:14:33 AM
 #18

Quote
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;

The label is not public. You can't easily pass messages via Bitcoin.

The idea is OK. I would have just used plain text instead of HTML. Bitcoin sends blocks in chunks of 500 -- splitting in chunks of 10 seems excessive. I don't like having to convince someone in the system to pull data from me.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
johnyh
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
February 18, 2011, 07:54:22 AM
 #19

Quote
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;

The label is not public. You can't easily pass messages via Bitcoin.

The idea is OK. I would have just used plain text instead of HTML. Bitcoin sends blocks in chunks of 500 -- splitting in chunks of 10 seems excessive. I don't like having to convince someone in the system to pull data from me.

Hi, thanks for reading in detail.

The payment idea would work though Smiley The payment is to given node. It is simply an ati-spam tool (to not have trouble like Frost).
Example: New node B joins network, and want popular node A to notice it.
Node A fortunatelly does offer such thing, for small payment (e.g. 0.01 BTC). Node A publish some Bitcoin address (of itself, or of the admin, or of admin friend, whatever).
Node B pay to this bitcoin-address related to node A, and node A will be somehow notified about the transaction and will be able to read the label.

The bitcoin addresses can be connected to BtcFn node, but also can be separated, in example friend of admin of node B can pay to friend of admin of node A, e.g. using TORed node to make the payment, or using another BtcFn node (other then B and A). All is possible Smiley Eventually though somehow the payment TX will reach a miner, will be incorporated into a block that some other BtcFn node D will pull into freenet, this will be observed by freenet-only, reading-only stealth BtcFn node X that belongs to admin of also node A, and in the end node A will observe node B to honor this payment. Even such scenario should work eventually Smiley
xel
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
February 21, 2011, 05:08:48 AM
 #20

Quote
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;

The label is not public. You can't easily pass messages via Bitcoin.

The idea is OK. I would have just used plain text instead of HTML. Bitcoin sends blocks in chunks of 500 -- splitting in chunks of 10 seems excessive. I don't like having to convince someone in the system to pull data from me.

Thanks for chipping in the bounty Smiley

Yes we could use plaintext as well, the only thing is that I wanted it to be a tiny bit more user frindly if someone pokes by hand to such USK@ address of a node. but this can be changed.

About the chunks and pooling, I dont understand the problem, what you mean?
If chain is 1023 blocks long now, then freeneters will download following files:
file with blocks 0..1000,
file with blocks 1001..1010,
file with blocks 1011..1020,
file with block 1021
file with block 1022
file with block 1023

this big packs of size 1000 blocks will be referenced for many days (for next 9000 blocks mined - because only then it will be repacked to even bigger pack of 10,000 block and the old pack 0..1000 will be no longer downloaded).
So, the bigger the pack, the longer it will be requested by every node using BtcFn. So it should stay easly downloadable.
As extra bonus, BtcFn nodes should periodically anyway redownload file to keep it fresh and cached in freenet.
Also such request may additionally improve anonimity even more (on freenet level) by making a bit more of a smokescreen of semirandom requests masking real activity from your freenet/BtcFn node.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!