That's perfect.  I love it.

They'll have to make due with the free TOR net which will hopefully be faster once all the pirates or whatever switch to premium nodes.




Agreed on the advantages; I don't think this disadvantage is a deal killer.  This part is the problem:




Sure, it's a simple DB of used codes...  But the table will be HUGE, require a unique key constraint (not a good combination), and it will have a constant stream of inserts from every relay node.  You can go distributed at the expense of some double-spends, but it's still going to be large and grow rapidly.

Why?  Even CPU mining will generate a result in under a minute.  GPU mining would have you going in seconds.




Yes, you're describing the "completely independent codes" scenario.

How will you prevent double-spending the codes without accounting?

I don't care for this twist myself.  Funding the insurance would be complicated.

Rather than getting dinged because some net split resulted in you signing off on the wrong half of a double-spend, I would prefer the motivation to be to get a reward for including the transaction as promised,




Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise.




The classic double-spend.  The miner can wait a few seconds before making the promise to ensure there are no conflicts; and the recipient can watch for it as well.  This will catch 90% of such attempts.

The rare exception will be where the network is severely split and the double-spender is able to exploit it to his advantage.  Someone selling a cup of coffee won't be worried about such cases, but a business subject to fraud - a wallet service for example - could simply wait until they has signed promises from 75% of the network before accepting the transaction.




Each time a miner signs a block they include a copy of a pubkey.  The merchant gets the last 1000 pubkeys from the blockchain.  If they want 75% of hashpower signing off, they wait until they have 750 signatures (or fewer: many of the blocks will have the same pubkey since most blocks are solved by a handful of pools; a pool which solved 150 of the last 100 blocks only needs to make the signed promise once).

It doesn't prove that it's approved by 75% of hashpower online right now, but 75% of the hashpower for the last 1000 blocks.

I imagine it as an incompatible fork of TOR.  When you go to build the circuit, nested tunnels are created to each successive relay node.  At that time you're already communicating with those nodes, so adding getwork/submit results into the protocol wouldn't be hard.





This would require centralized accounting.  If the codes are completely independent it would be a LOT of bookkeeping.  If the codes are pooled on an account that's used for a few minutes at a time, each account could only be used with one relay node, AND only when connecting to that relay node through a specific path.  That's a lot of complexity to add.

It would increase setup time since you would have to mine for several minutes to connect to the first node, then several minutes for the next node and so on.

If you allow premining or saving unused credits, it would also eliminate one of TOR's protections: forward secrecy.  If you save the account number on your computer, someone who logged your connection from an exit node would then be able to prove it was yours after seizing your computer.

For all those reasons I think it's better to mine in realtime for each node, only accumulating credits for as long as your tunnel is up.





This is a concern for any of the proposals.  Looking at it in a bigger picture than difficulty: you're providing value (a certain amount of security for Bitcoin) in exchange for value (transit).  Your hardware will be able to contribute less value as time goes on.

Net effect: the amount of transit you can afford with a given piece of hardware decreases.  However, an average PC only gets more powerful with time.  Right now you could probably mine in realtime for a reasonable amount of bandwidth even on a CPU.  In the future even low-end GPUs will suffice.  If ASICs happen and even GPUs become irrelevant, TOR-mine users will be able to buy a low-end HashASIC for $50.  For those who simply can't afford it, there's always the regular free, slow, TOR network.

You're making some big assumptions and stating them as fact.  I'm pretty sure that a simple, workable scheme to pay for transit with mining hashes can be made without compromising anonymity.

I'm skeptical that paying with BTC directly would work, but I'm not done with the paper linked above yet.  They're doing a pretty good formal analysis of the idea from what I've read so far.

BTC is conspicuously missing from the deposits and withdrawal stats. Can you add it?

Commendable.  I'm glad to see you disclose deposits and withdrawals.  I've been interested in this data for some time to help evaluate the Bitcoin economy as a whole.

From a security standpoint I would be interested in more information on how, technologically and operationally, you are handling security.  The big one (90% of BTC in cold storage) is there, though, and appreciated.

The major problem I see is that a corrupt miner could make false Promises.  I don't think that's a show stopper though.  

Just restating it how I envision it - correct me if I'm wrong:

Alice makes a payment to Bob and transmits the transaction to the network; transaction is flooded;
All active miners sign it as a Promise to mine it; the signatures are flooded;
Bob receives the payment transaction and confirming signatures;
Bob waits until he has a reasonable number of Promises before delivering goods.

Each block would have a miner's pubkey that can be used to sign future Promises.  If the keys used in say 3000 of the last 5000 blocks then sign the transaction, it's basically good - anyone who could make those signatures and then fail to mine the transaction into the next block could just as easily make a 51% attack.

We would have to decide on how large a sliding window to use.  The amount of traffic generated by allowing every miner who's ever mined a block to make a Promise would become unwieldy.  Nodes should stop relaying Promises signed by pubkeys that haven't been in the chain recently.

I suggest making the "Percentage of Promise" be (the sum of difficulties of blocks with keys that sign the transaction) / (the sum of difficulties of all blocks in the sliding window).  That would prevent some miners having undue weight when the difficulty changes.

Just at first glance I think it works.  Great idea.

I just read the abstract.  That's good stuff if it works.  I'll read the rest of it when I get a chance.  Thanks.

TOR provides better anonymity than VPNs / proxies.  It relays through three nodes: the entry node doesn't know what you're visiting; the exit node doesn't know who you are; and the middle node prevents the other two from being able to compare notes.  Placing those nodes in different countries prevents them from being compromised by court orders to log traffic, for example.  It's also advantageous that each of your connections can't be traced back to a single payment address.

Yes.  Just like a mining pool you would get work then submit partial results as proof that you're performing the work.


Yes.  There is only a limited supply of people willing to donate free bandwidth for other people's anonymity.  There are enough that web browsing is usable but slow.  If it generated enough revenue to cover bandwidth costs, I bet there would be a ton more relay nodes.

Authenticating to exit nodes would weaken the anonymity unless your credentials are short-lived.

That's the idea.  More likely it would be two tiers of nodes: fast ones that require the fee (and can therefore afford tons of bandwidth to service as much traffic as possible), and the regular nodes that provide free service (and are pretty slow because tons of people are using them for everything).

Having given it a bit more thought, I don't think paying BTC for MB-transit would work.  Paying every relay node from the same wallet would break TOR's anonymity completely.  Effectively you may as well pay a single node for VPN service, which is already available for BTC.  The only way around it would be to have hundreds of wallets to pay each relay node separately and that just isn't practical.

So I think I like your original idea of paying with mining.  You could simply connect through the TOR net as usual, except along each hop you get_work for mining.  Each share you submit will buy a small amount of bandwidth - say, 100 KB per share.

This would work well in several ways: 1) it preserves anonymity, since each get_work is completely independent and ephemeral; 2) it's much faster since submitted shares are instantly good, whereas regular transactions take time to confirm; 3) it avoids having to prepay in relatively large blocks to avoid excessive transaction fees.

Having done a bit of mental math, CPU mining would be marginally usable.  Your average speed wouldn't be very good but you could prepay ahead a little and get fast bursts as you need them - typical web surfing would probably work fine, much better than TOR is now.  And anyone with a GPU would have all the bandwidth they'd reasonably need...  They could torrent over TOR.

So in short, your idea is good, and you had it right from the start.  Now you've got me thinking about other ways that mining shares could be used as microtransaction currency.

That's an interesting idea.  I wouldn't make the clients mine, though.  Not everyone has access to a reasonable mining rig.  Just have the clients pay BTC for premium bandwidth.  For instance, offer to pay 0.001BTC per MB of transit.  That's highly profitable for the relays - it's a 100x markup over premium internet transit.  And it'd be a reasonable price for many users who want to go fast.

The two problems I see: 1, you'd have to prepay for your bandwidth, though that's not so bad when you can do very small microtransactions with BTC;  2, if you get your BTC from a non-anonymous source it defeats the purpose of TOR.  Clients who care could mine their own; most won't care since they're not worried about a threat strong enough to trace the coins back.

Instead of creating a transaction container and then sending it to the receiver COD, you could simply create a "pay another transaction's fee" transaction type.  There's no need to cryptographically guarantee that the postage is only paid by the recipient, so let anyone throw in some extra tx fee.

On the sending side this would make it simpler - you just send the transaction the same as any other.

On the receiving end you're not forced to pay the extra tx fee until you decide you're tired of waiting and want the transaction mined ASAP, instead of with the "container" method where you'd have to make that decision at the time you send the tx to the network.

We saw one maybe a month ago that was pretty clearly an overflow bug where someone was storing satoshis in an int32.  This one's not that; it's almost like someone swapped the fee and the change.  But I doubt it's a regular client or we'd see more of it.

I'm not sure there's anything to be done about it unless someone posts here wondering what happened to their coins.

While the returns would be small, the cost of mining is also small.  Instead of buying racks of GPUs and feeding them considerable amounts of electricity, transactions could be signed with no more processing power than a smartphone...  A fraction of a watt for the current scale of the Bitcoin economy.  If you had a large savings account, would you take zero return for free or 0.5% for essentially free?

The efficiency is a compelling argument, and I can see how it would work.  It's just the secondary effects that worry me.

That's not really true.  In a Bitcoin economy, governments can still bail out all the losers they want with as many BTC they have.

Also don't forget that MtGox bailed out bitomat.

Bitcoin is a big step forward in money, but The Market is a lot bigger than just the currency that is used.

https://campbx.com

The depth is pretty thin but I've found the arbitrage bots will take any reasonable order.

I'm a satisfied customer so far.