I think you're so much skeptical about namecoin. It works pretty well *now*. Namecoin is still very young project and there may be some development fixing those issues. There's only few namecoin users right now, so namecoin update can work like bitcoin updates year or two ago; satoshi simply posted new bitcoin version and everybody updated without any boring discussion like BIP16/17 :-D.

I see bigger threat in lacking namecoin development than in missing features in current implementation.

I agree with you, using bitcoins directly isn't sounding idea, because bitcoins have serious problems with anonymity. However bitcoin mining is pretty elegant way how to obtain some valuable item anonymously. So bitcoin(mining) + intermediate layer for distributing the value in the tor network (redeemable codes in my proposal) + Tor should work pretty good.

Mining directly for Tor relay won't work very well, for many reasons. Firstly, you cannot communicate with relay directly, because it leaks your real identity (IP), so you need to build circuit to the hidden service linked with the relay and you need to do this for every relay you want to use in the future. It's not easy and definitely not elegant.

However the idea of "mining for bandwidth" _is_ pretty good. I agree that using Bitcoins directly for paying for bandwidth isn't anonymous enough for common users, although it still may work good enough for some users (not everybody care about 100% anonymity, many of Tor users simply need to avoid IP limitations etc).

My basic proposal is following (it can be extended in many ways, but I want to describe main idea):
1. Anonymous mining pool with slightly different interface; pool will return unique redeemable code for every submitted share instead of accounting 0.000001 BTC on some user's account. Miner can change identity (use different Tor circuit to pool hidden service) every few minutes, so pool have no link between issued redeemable codes.

2. Relay publish some contract about premium bandwidth to Tor relay directory (public list of Tor relays).

3. Tor client has its automatic circuit manager, which can be turned off easily. Instead of buildin defaults, custom circuit manager should pick information about premium bandwidth nodes from tor directory and build circuit using preferred relays. Tor client should pick few redeemable codes for every relay in future circuit and encrypt them using relay's public key (already exists in tor relay directory) and ask entry node to route those encrypted codes to relay during building the circuit.

4. Every relay during building the circuit will receive redeemable codes and redeem them against the issuer (link to issuer's API should be as a part of the data). If redeeming is succesfull, relay should use premium bandwidth for given circuit.

In this way, using premium circuits might be really anonymous, because there's no identity leak. Also extending the protocol should be pretty straighforward; only distributing of encrypted redeemable codes must be implemented into the currect Tor protocol.

Principle of redeemable codes can be pretty flexible, too. When some people don't care about anonymity so much, they can  "trade" bitcoins for redeemable code with some issuer hidden service. In this way, user is as anonymous as much used coins are laundered. There's also identity leak because issuer knows which redeemable codes are linked together (because they were traded for some bitcoins in one operation). Of course this can be obfuscated somehow (one guy can buy X codes from some issuer and then sell them anonymously for drugs or guns on SL, so drug dealer can use premium bandwidth on Tor and his identity isn't linked to any coins used for buying redeemable codes).

There are still some problems:
* Tor relay can accept redeemable codes, but don't provide promised service quality.
* Although Tor relay need constant amount of coins per MB (relaying is not affected by Bitcoin difficulty), rising Bitcoin difficulty can make this concept useless for common people without strong mining rigs.
* Using specific relays may be pretty insecure. Until premium bandwidth will be provided by the majority of the network, attacker can provide significant count of premium relays, so there will be pretty big chance that both entry and exit node will be under the control of the attacker. However this can be solved (for example) by paying for premium bandwidth only on exit node, because exit node is usually the bottleneck.

I see, still we're talking about almost 21.000.000.000.000.000 domain updates in current system.

However I agree that never ending inflation may work better than hardcoded 21mil limit. Namecoin isn't a currency and I don't see real reason to limit coins in existence (especially when system is systematically destroying them).

afaik there's some algorithm which calculates price for domain from last x blocks. So yes, those coins are destroyed, but when namecoin gets some popularity and namecoins will be more expensive, then domain will cost maybe eve 1 satoshi, which means we can still have bazilion of domains.

Can you publish daily/weekly/monthly amount laundered on the site? I think it's important for the people to know they're not alone using this service, which breaks the anonymity. I think *this* was the concern of fivemileshigh.

My pool is already providing tor hidden service for mining, see onion adddress on http://mining.bitcoin.cz. It works with latest poclbm very well, thanks to direct SOCKS5 support in the miner.

There are two main reasons for tor mining: privacy and ddos protection. Pool is using different (secret) IP address, so even when main mining interface is down, tor mining should work nicely.

Looks like a bug in bitcoincharts.com feed... I'll ask there.

Oh, sorry. I voted "no", I don't think this war affects price in any direction. It is mostly a storm in the cup of tea. Some p2sh solution *will* be implemented, now the question is *when*. Then proper implementation of p2sh in clients can affect price in positive direction.

http://blockchain.info/p2sh - yes, I'm voting for BIP16, because it was general consensus until the mess about BIP16/17 started. So far it looks like BIP16 voting don't reach >50% until 1.Feb, so we will see what will be next progress. I'm affraid that BIP wars distracted bitcoiners to pick ANY solution because they're affraid that something strange will happen, which will only slow down p2sh implementation.

Some people are spreading FUDs, but actually nothing bad is going to happen in any case.


Not likely. And if so, nothing happen. Bitcoin network is designed to "repair" from blockchain splits by self. Also nobody wants to be on blockchain branch, there's pretty good incentive to go with the majority of the miners.


Common people don't need to understand it. Actually the discussion should be much more technical, but thanks to many misunderstandings it was turned into political mess. I hope people will calm down and will discuss more like human beings and will keep discussion more factual.

I see only one risk which can affect bitcoin price. It's that bitcoin developers will be seen as a group of untrustworthy sociopaths which are unable to talk each to other. And it's not related to BIP16/17, it's more general issue.

? I'm just voting for p2sh, it does not mean that pool will split blockchain when there won't be a consensus. Please don't start any FUD...

It is combination of some natural variance coming from score method as described and simulated here: https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 and the effect of added hashpower on the beginning of the round from pool hoppers. I recommend you to check daily rewards more than round rewards, because round rewards are influenced by many factors, not only your own hashrate.

Few days ago I found http://btcrelay.com/, service which allow splitting incoming coins to many different bitcoin addresses. I see many useful use cases for such service. You can, for example, split pool payout, one part forward directly to the exchange and let it automatically trade for USD and second part forward to savings wallet. It is pretty nice way how to automate something what I did manually once per week before launch of btcrelay service.

pent, you didn't say anything in the direct oposite of my post :-).

We can discuss what is main purpose of Internet/Tor/I2P, but the fact is that Tor is TCP mixing network (not HTTP-only mixing network).

Very nice! I was thinking about the same project for Tor. Unfortunately I'm too busy so I hope somebody else will do the job for me :-)).


This is incorrect, Tor is acting as a SOCKS5 proxy and is relaying any TCP traffic, not only HTTP.

/OT/ *check mail box* 6480 unread out of 17331 in my inbox, really. You should also learn how to use filtering, lol ;-).

Don't worry, this likely does not happen. Nobody want to work on forked chain alone...

Maybe you should subscribe to bitcoin dev mailing list?

Oh, finally something where I can agree :-).