Bitcoin Forum

I think I've found a way to combine hashcoin's method for Instant TX for established business relationships (https://bitcointalk.org/index.php?topic=25786.0) and Gavin's more recent ideas for Off-the-chain transactions (http://gavintech.blogspot.co.il/2012/07/off-chain-transactions.html) to allow any party to send bitcoins to any other party, with instant confirmation, without adding to the transaction count of the blockchain (thus scalability-friendly), with absolutely minimal need for trust in a third party. The disadvantage is that it requires bitcoins to be tied up, so it is less effective the more time value bitcoins have.

hashcoin's method (https://bitcointalk.org/index.php?topic=25786.0), if I understand it correctly, allows establishing a payment channel from user A to user B with the following properties:
1. A has to tie up X BTC for a period of time decided in advance (say a month).
2. During this time, A can't do anything with those bitcoins other than paying to B.
3. Establishing a channel does not constitute payment. B can't take the money, and if B vanishes A will still get it back at the end of the period.
4. While the channel is up, A can use it to pay B multiple times, up to a total of X BTC.
5. Each such payment is done by private communication between A and B, doesn't require communication with the network or a separate transaction, and is instantly confirmed - once B gets the necessary information from A, he can be sure it cannot be reversed.
6. At the end of the term, all payments are settled together with 2 small transactions.
7. If A vanishes mid-term, B can still claim his payments so far at the end. If B vanishes mid-term, A can still claim everything that he hasn't paid yet, and in some cases even the funds that he has paid.
8. The receiver can close the channel before its expiration date if it's no longer needed, freeing the tied up funds.


The question is what to do if I don't know in advance who I'm going to pay. And the answer is simple - have an eWallet of sorts that never holds anyone's money, but simply establishes payment channels to and from each of its customers.

Say Alice and Bob are both users of the payment processor Trent. Trent establishes channels to Alice and Bob, and Alice and Bob establish channels to Trent. The amounts and period will be determined by how much money each expects to move.

If Alice needs to pay Bob, she pays Trent through the channel, and informs him that Bob is the recipient. Trent then pays Bob through the channel. The payments are instantly confirmed and there is no need to add a transaction to the blockchain for this.

Instead of one transaction per payment, we have about 4 transactions per user per period over which there can be many payments. And the processor is never trusted with more than the amount of a single payment by a single customer.

The BTC amount of the channel, which is constantly tied up, should suffice for the payments that are expected to be made over the period. The shorter the period, the less funds need to be tied up, but the more transactions need to enter the blockchain in a time unit. There's a tradeoff for which an optimal solution will be found on a case-by-case basis. No doubt, Trent will charge his customers for the service of tying up his own funds for the downstream channel. Either party of course can create a new channel when the current channel end up not sufficing, at the cost of more blockchain transactions.

There is no need for Alice and Bob to be using the same payment processor. The processors can have reciprocity agreements between them and allow funds to be sent from one to another. If there is some trust between them, they can cancel out small payments without saturating the channel, reducing the amount they need to tie up for this.

There is very little barrier of entry to becoming a processor, so there will be many highly competitive processors.

Unlike the current version of Gavin's idea, this is resistant to collusion, to accounting errors of the processor, and to the processor vanishing thus making the coins unspendable.


It may be hard to imagine anyone tying up his funds for this, when weekly interest rates of 2% are easy to be found. But this isn't going to last forever - as Bitcoin grows and stabilizes, ROI for safe investments will settle down, and the time value of money will approach what we are familiar with in traditional economics (probably even less, because there is no inflation). It will be reasonable to keep bitcoins as-are as a long-term investment, and by that point one may as well tie them up in a channel to his payment processor.


EDIT: It appears I've missed this comment (https://bitcointalk.org/index.php?topic=25786.msg480826#msg480826) by jav, where he also mentions the receiving end can be a payment processor. But he doesn't go as far as suggesting that the processor should also use outgoing channels.

I think it would work, but I can't see how the payment processor makes any money.  As you said, his own funds are tied up in multiple connections; so all that money has to be rented somehow, and that doesn't even cover the costs of running the service itself.  I think that this would work great for long term reciprocity agreements between major online bitcoin payment processors, but in order for this to be beneficial there must be more than 4 transactions between users of a service.  For most this is unlikely, as most paypal users don't average one a month.  Reciprocity agreements between large online wallet services, however, can expect to have at least dozens of transactions between their userbases in any given day; many of which will simply cancel out.  A pair of payment processors could choose to tie up, say 1000 bitcoins in each others' service (or use this method to do so with a meta-processor) with the agreement that, should the transactions total to an imbalance of more than 50% of the funds in either direction, the processor that owes produces a 500 bitcoin transaction automaticly, thus rebalancing the flow.  This can consolidate hundreds, if not thousands, of individual transactions on the bitcoin network if the mutual buffer is large enough to permit many small transactions between userbase members, most of which simply cancel out.

The operational costs are very low. The time value of money will have to be paid by the customer, but it shouldn't be prohibitive. If the interest rate is 0.5% per month, that's more or less the cost of using this scheme (better than Bit-Pay's 1% or PayPal's 3%+), and you get instant payments which can be arbitrarily small. And if you make it shorter than 1 month it is proportionally less - with 6 days it's 0.1%. And, if a customer both sends and receives payment, and is willing to trust the processor with a small amount, he can cancel out most payments and thus not need a large channel, decreasing the cost per transaction.

Bitcoin and its ecosystem isn't supposed to replace just PayPal. It should replace cash, checks, credit card, bank transfers etc., and allow a whole new world of microtransactions. The latter is one key issue this proposal solves - for small transactions 0.5% isn't much, but the cost of processing the transaction by all network nodes in the world is.

Can you explain in a bit more detail what exactly a channel is ?
(as that is where the magic seems to happen)

The explanation is at the linked thread (https://bitcointalk.org/index.php?topic=25786.0). I'm building up on hashcoin's work, not redoing it. I added another link in the OP.

This is all fine, but if a customer is willing to trust the processor with a small deposit, then he doesn't need any funds tied up into the channels.  Once again, I think that this idea is sound, but is more likely to be used at the macro level.

Agreed.

What are the friction points for this channel arrangement and how might that affect it's adoption at the micro level?

Without a channel, he loses the ability to make instant payments which are larger than the deposit. Funds in the deposit are also tied up and require a transaction to replenish, so they only make sense if:
1. The customer pays unpredictably, so he doesn't want to "waste" a channel which he ends up not using - he'd rather send a deposit and use it if and when he needs.
2. The customer receives and sends payment frequently, and he wants the deposit to act as a buffer to cancel out adjacent sends and receives. In this scenario even a deposit much less than the volume can absorb most of it, decreasing the channel requirement.

Either one of just a channel or just a deposit is fine for some use cases, but their combination is much more powerful and flexible.

The friction is the need to broadcast 2 transactions per channel, and tying up the amount of the channel for its duration (the tradeoff is - longer channels need more funds to tie up, but require less transactions per time unit). This means that this system has a cost, which depends on the time value of money and the use pattern.

Wait, what?  Are you saying that the user would be able to make instant payments in excess of the funds he has tied up into the channel?


Which covers the use case of 99% of all Paypal members, which was my point.


Which covers the use case of half of the remaining 1% of Paypal users.


This I can agree with.

No, I'm saying that the funds he has tied up in the channel can be much more than what he would have in a deposit, since he doesn't need to trust the processor with it.

As I said Bitcoin is not a replacement for just PayPal. Actually the average person's expenses are fairly predictable - they're equal to his income minus the amount he's saving. Many of the specific payments are also known in advance, bills, groceries etc.

Neat idea. The loan that the processor gives you is entirely risk-free, so it'd probably be pretty cheap. I could see this being commonly used for micropayments and instant transfers. It might even be the main transaction method in the future if the max block size stays fixed at 1 MB and blockchain transactions get really expensive. Even this might create too many transactions, though.

I'd guess that channels for receiving BTC would be free. The main benefit is to senders, who get their product instantly and don't have to pay fees for every transaction. But payment providers can only offer these benefits when recipients have channels set up.

Someone should make a diagram describing hashcoin's payment system. It's kind of difficult to understand.

That's an awesome idea Meni! This does open up new markets that won't tolerate delays.

I have not understand all the details you have exposed but I think that something like ripple (https://ripplepay.com/) could ease to obtain most of the benefits you are looking for.

But the use case that we are examing here is comparable to one or more paypal-like services.  So the comparisons are valid.

Yes, we are all very familiar with ripple.  It has it's place, but doesn't remove trust from the metric.  Something ripple like would be useful as a overlay network, perhaps permitting bitcoin users to use the ripple like network to send/receive small payments indirectly to/from vendors that they don't personally know without tiny transactions on the bitcoin network.  Something similar might be usesful for smaller online wallet services to participate in off-bitcoin-network micropayments without actually having a reciprocity agreement with the other party's service.

You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.


from etotheipi in mailing:

To me it looks identical to hashcoin's, what am I missing?

Looks identical to me, except that it's intended to pay for a wifi hotspot access, not just anything.  Question, can Lock_Time be extended with newer revisions?  If it can, then there is no reason that this process cannot extend much longer than the initial lock_time, allowing the user to extend the agreement from the original period (be it a day or a month) out for as long as the counterparty would allow.

Somehow, though, I suspect that extending a lock_time is prohibited for some technical reason that I don't understand.

The first transaction isn't replaced, it just has lock_time. The second transaction doesn't have lock_time; the first version starts at seq 0 and then all new versions of it are final. The versions of the 2nd transaction don't replace each other, rather they are kept private and only one of them (at the choice of the receiver, who will choose the one paying him the most) can be broadcast to replace the first version.

No. If the lock time is extended after the channel is established, transactions after the lock time is extended can be easily reversed by the sender.

The difference is what they mean when saying  - "set sequence number to zero"




hashcoin and Mike Hearn argued about necessity of transaction replacement protocol.

Replacement isn't needed for this. The two parties can communicate their tx versions directly.

Ok, now I'm confused. You don't need a replacement for every new version of transaction 2; but you do need a replacement for the first version. Alice won't sign transaction 1 before she is sure she can get the money back in the end; this happens after Bob signs the first version of transaction 2. But after that Bob needs the power to replace this first version with the version that pays him; for that he needs replacement.

That was the major point of the thread: Rapidly adjusted micropayments and multisig/P2SH (https://bitcointalk.org/index.php?topic=66521.0),

and that seems to be the resolution:

The writeup on the wiki is identical to hashcoins initial proposal, I think, except with a motivating example (wifi hotspots) to illustrate why it's useful.

The reason for nLockTimed transactions to stay in the memory pool and be replaceable is to provide a kind of predictable "negotiating table" for the parties. This is a common point of confusion. Hashcoin eventually understood this and decided he still didn't like it :) but that's more because it got disabled at some point and we'll need to reactivate it. Preferably ASAP but we're all busy with other projects right now, it seems.

Replacement is required because otherwise as you increase the value sent via the channel, one party (the paying party) can always reclaim any value sent on it by broadcasting the first transaction to the network. It doesn't matter that the receiver has a signed, valid transaction giving them more value, the miners memory pool is already full with the earliest tx and the later versions of the transaction will be treated as double spends. With replacement, if the payer tries that, the receiver has a window of time (until nLockTime) to broadcast the later versions and override the senders broadcast. As long as you cleanly terminate the channel shortly before the end of the lock period, this protocol is safe for both parties.

This system has a flaw lol.

Merchant: fuck you, you are not getting your 8 BTC. Sign & Take 2 BTC or 0.

I'm not sure what you are talking about, but did you actually read how the system works? The receiver can't confiscate funds he wasn't specifically paid, he could die and the sender still receives the tied up funds at the end of the term. You might be confusing this with an escrow transaction, where this could be an issue.

This scheme clearly needs working replacement and time-locks. So unless replacement gets implemented in some form, it's unusable.

Personally I think the replacement counter as it is in the specification doesn't make much sense, since it doesn't coincide with miner interests. A natural system uses the value of the time-lock as primary version number, and the transaction fee(per byte) as tie breaker.

Btw with a better scripting language you could trust the processor even less. You'd need a signature verification operation that takes the message it should validate as an additional parameter, instead of implicitly using the current transaction. That way the processor can only redeem the money you sent him by producing a signature that unlocks a transaction from him to the receiver.

----

On important point you didn't mention is that the receiving end can terminate the channel at any time. So the bindup effect isn't as severe as some think. This also allows terminating the bidirectional channel when both sides cooperate.

----

One thing this system lacks is strong untraceability. I didn't find a way that offers anonymity while not entrusting the bank with any money, so untraceable  transactions still need to trust the bank a bit. But at least this scheme allows relatively low trust together with few on-chain transactions.

He can? Transaction A has LockTime, so even if transaction B sending the coins back is released, the sender can't use them.

For untraceability you could use a different method (or combination) with a different set of tradeoffs, such as oblivious mixing transactions (https://bitcointalk.org/index.php?topic=54266.0), Open Transactions, etc.

The step 3 transaction is not timelocked. The receiver can (and if he wants his money, even must) broadcast it before the timelock expires. At that point the receiver gets all spent coins(or less if he so chooses) and the sender gets back his unspent coins instantly.

The sender can't terminate the channel by himself, but he can ask the receiver to terminate the channel. There is no reason for the receiver not to comply.

I'm just lamenting that you can't combine the trustless nature of this scheme with the untracability of chaumian cash. My planned project requires strong anonymity, so I need to trust the bank more than I'd like to.

The last transaction isn't timelocked, but its input is the output of the first transaction, which is timelocked, so it can't be executed before the timelock expires.

Mixing transactions don't require you to trust anyone. Though that by default doesn't give you instant/scaleable transactions.

A transaction that has not yet reached its nLockTime but which has finalized sequence numbers is finalized. See the code:


So if you have an open micropayment channel, if both sides sign a transaction with UINT_MAX sequence numbers and broadcast it, it will replace the timelocked transaction and the transaction will confirm immediately.

Not sure if you or me misunderstand hashcoin's scheme. But I independently designed a scheme which looks equivalent to me. Perhaps the description from my design docs is a bit clearer:

Transactions `T5`, and their input `T2` aren't time-locked. So Bob can claim his money at any time, giving the remainder to Alice at the same time.

You're right, I misunderstood/misremembered the method.

I believe developers underestimate how transaction replacement feature is important, e.g. utilizing this proposal a business dealing with customers bitcoins wouldn't be required to hold private keys with a substantial balance and the Bitcoinica hacks (I stumbled on typing the word "hack" in plural) wouldn't have such devastating results.

Another thing about transaction replacement is that it would enable a lot of unique uses of Bitcoin e.g. mesh network where every node has monetary incentive to provide bandwidth, new business model for hostings and web sites where a user pays per kilobyte of downloaded content, ability to pay for extra bandwidth on ToR network which would explode the amount of nodes.

Relevant recent IRC discussion: http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/07/11/6#l3981048

Bottom line: I think transaction replacement is important, but if we just enable it as-is then I think we open up the entire network to an easy DoS attack.

And I think the incentives for miners aren't right. I think the rule for what version of a transaction will be included in blocks has to be something like "the one that pays miners most OR the one that pays miners first (if there are several with the same fee)."

So I think a scheme where transaction fees are increased, or lock times are decreased, with every transaction replacement is the right way to go.

There are several discussions in parallel in that IRC log.

To summarize, Gavins concerns are

a) That being able to replace transactions could allow attackers to DoS the network by constantly replacing transactions (you still need to check the signatures each time).
b) That miners have an incentive to not perform the replacement if the new tx has lower or equal fees to the version currently in the memory pool.

My responses were

a) We should rethink/rework DoS protection as a prioritization problem. TX replacements should be prioritized lower than new transactions and compete for whatever CPU time is available. Replacements of transactions that were recently replaced get prioritized lower than others. The result would be that you could drive CPU usage on the network to 100% for a while but it wouldn't achieve the "denial" part of DoS, making such an attack worthless.

b) Miner incentives are already not entirely aligned with pure selfishness, as we see sometimes with miners who drop fee-paying transactions or don't include any at all. Despite that Bitcoin still works. If miners routinely broke the rules and rolled back transactions to claim higher fees, the feature would simply become worthless and nobody would rely on it anymore, wiping out entire classes of applications that depend on micropayment channels (and other constructs that need replacement to work).  That wouldn't kill Bitcoin but would reduce its utility a lot. So I don't think miners will routinely start to do this, even if there were easy patches available. It'd be a very short term strategy.

Minor nitpick: I think it's better to mine the transaction with the earliest lock time over the transaction with the highest fee. That increases the probability the miner gets any fee at all.

Combining that with Mike's suggestion of prioritization, I think there's no need for any increase in fees at all for any transaction replacement that isn't actually trying to flood the network. As long as there's any fee at all, miners should mine the earliest expiring transaction. If the sender is unwilling/unable to make the lock time earlier, she would have to increase the fee.

Yes, that makes sense. But it's only necessary if there's a large conspiracy of miners who are trying to do this all at once.

If you're just worried about your counter-party trying to mine a rollback block, it's not really a concern because they'd have to get very lucky to mine the next block after the lock time expires. And for micropayments, well, who cares.

I'd probably start by just using a constant lock time for simplicities sake. If miners do all start modifying the code to allow rollbacks to higher-fee-paying transactions, the micropayment channel code can be updated to count-down nLockTime (I guess it'd be specified in terms of blocks to make this easy), which should change the incentives again, at a small cost of complexity and perhaps inconvenience/efficiency. But the fact that this adaptation exists means hopefully that conspiracy should never occur.

Good. I'm happy now :)

Looks like the work boils down to:

a) Writing unit tests
b) Doing work prioritization for tx verification