On Friday 17 December 2010 16:03:41 Matthew Toseland wrote: > On Friday 17 December 2010 14:02:31 xor wrote: > > Hi, > > > > I have just read the following Wikipedia articles: > > [1] http://en.wikipedia.org/wiki/Anonymous_internet_banking > > [2] http://en.wikipedia.org/wiki/Bitcoin > > > > I am not certain whether Freenet can meet the requirements for the > > mechanism which is proposed in the article [1]. > > Completely out of scope IMHO.
As far as I have understood it and you have stated yourself below, bitcoins transactions are not anonymous, you can establish that the identities themselves are anonymous but we would need anonymous transactions to a neutral bank to get bitcoins "out of Freenet". The ability of getting them out of Freenet would be necessary for people actually being interested in them... And [1] was linked from [2] so I thought it might fit. (Basically, transactions from anonymous identities to anonymous identities should be public because it can be used for a web of trust to judge whether someone is likely to pay or not. Transactions between bank accounts and anonymous identities have to be anonymous to guarantee that you can get your money anonymously into/out of Freenet. Transactions between bank accounts and other bank accounts have to be public to guarantee that the bank is not corrupt...) > > I am also not certain whether Bitcoin provides mechanisms for anonymous > > transactions. > > Bitcoin is not anonymous. However, anonymity can be layered over BitCoin, > at a cost - using mixes to prevent following the money, and using Tor to > connect. How do mixes work compared to [1] ? > Basically a traditional digicash system uses a central spend tracker to > identify whether a coin has been spent. Bitcoin replicates the tracker > across all online nodes, but does not provide anonymity. Yes, and we do not need anonymity within the anonymous identity and non- anonymous bank subnets, we would just need anonymous transactions between them as mentioned above. > > However, if we could combine Bitcoin with the mechanism in [1] and > > implement it in plugins called "Freepay" and "Freebank" this would for > > sure be a killer > > > application: > Blind signatures are not relevant to Freenet. Well but they are relevant to getting your money out of it / into it, right? > > Consider Freepay being an implementation of Bitcoins on top of Freenet. > > Consider Freebank being a framework for anonymous transactions over a > > bank provider who runs Freebank. > > > > Let the FPI (Freenet-foundation) provide a bank X by running Freebank. > > Have a transaction fee of a certain percentage. Allow both conversion of > > real money into bitcoins and bitcoins into real money. > > There are lots of bitcoin exchanges. There might as well be lots of users who provide bank services by running their own bank via Freebank, to distribute the load and to guarantee that you find a bank which you trust. > > The FPI uses the transaction fees for financing the Freenet project and > > it's bank services. > > Anyone else can also provide a bank by running Freebank. > > That would make sense if we were providing some sort of value-add. But > we're not. The value-add of the banks would be that they provide the ability to get non- anonymous real money / non-anonymous bitcoins into anonymous Freenet identities. > > And for creating a Freetalk/WebOfTrust identity, you have to pay bitcoins > > anonymously to the seed identities, which come from the FPI. > > Because bitcoins are worth real money, spamming can made so expensive > > that it will not happen. > > Right. We *could* use bitcoins for bootstrapping. The problem with that is: > 1. People will NOT give us real money just to get started! And we can't > make it low either because of credit card fees. 2. On many slower systems > (especially those without a modern GPU) generating bitcoins will take a > long time. 3. It might not solve bootstrapping without trusted parties > such as the seednodes - "insert a coin to URI X" would not work, for > instance (because there is no way to verify it at the node level), and nor > would coin-protected inserts (because nodes would multiply to increase > their payment). It could be used as an additional bootstrapping mechanism besides captchas, for users who want to make sure that they do not see spam. > > > As a bonus, the FPI earns money for funding the project. > > > > In general, publishing good content to Freenet or Freetalk is encouraged > > because there will be a "Pay a small amount"-button next to each Freetalk > > post, etc. > > > > This sounds AWESOME. I hope it is possible. > > If we implement this, it will cause an literal earthquake in IT news and > > fund the project for ever. > > I doubt it. Well, I was being euphoric, but still an out-of-the-box anonymous payment system for anonymously published content does not exist yet AFAIK, it would at least get some "academic" attention. > > I will definitely help with implementing this after Freetalk. > > But someone needs to do the maths, I cannot. > > So please, somone figure out whether this is mathematically possible. > > It is not a matter of mathematics. > > Tying Freenet to any sort of digicash system does not solve any problems, > and increases the political cost of installing Freenet for no good end. It would help the amount of content very much. - Freenet needs more content. > > Plus, bitcoin relies on a CPU arms race, eventually stabilising at: > Total energy cost = (inflation * currency supply) / cost of a unit of > electricity At some point in time finding a new bitcoin will be like a million lottery win, no? So only maniacs will do it anyway, normal people will just buy them with normal money because hopefully they are a well-known payment system. - As far as I have understood it, the fact that they are computed is just some mechanism for distributing them fairly while they are new? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101217/fa56e509/attachment.pgp>
