It's still very much alpha-stage, but it should be usable if anyone wants to start developing applications that make use of nanopayments. I would love any feedback on documentation clarity, bugs, feature requests, or anything else about it! So, yeah... have at it!
According to the thread, the same functionality can be achieved using the micro-payment channels system?Apparently not, that refers to the OP's version.
So,
Bob creates a transaction that pays 0.01 BTC from himself to <public key> which has a hash of H.
Bob says to Alice "Create a transaction which pays 1 BTC to me and is paid from <tx-hash> output 0" and also signs it with "anyone can pay". <tx-hash> can be any in the range from S to S + N, when S = H - rand(N).
With "anyone can pay", Alice can add extra inputs without invalidating Bob's signature, but she can't change the output (sending the money to Bob).
Alice sends the transaction to Bob.
If <tx-hash> matches, then Bob can submit both his transactions to the network.
The risk is that Alice will submit a transaction spending the input at the same time she sends the transaction to Bob. However, she doesn't know which of the 1000 transactions is the valid one.
Cost to double spend: f (since you have to pay the BTC fee to add the transaction in the block-chain)
Benefit of double spend: V / N (since that is the expected loss of not double spending)
As long as f > V / N, then it isn't worth double spending. The means that N has to increase as the value goes up. Ironically, the transaction fee makes this service useful and also adds to its security.
That's pretty cool.
