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