Topic: Trustless, instant, off-the-chain Bitcoin payments - page 2. (Read 9729 times)

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.

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.

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

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:

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.

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

I have not understand all the details you have exposed but I think that something like ripple could ease to obtain most of the benefits you are looking for.

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

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.

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.

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.

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.

Agreed.

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

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.

The explanation is at the linked thread. I'm building up on hashcoin's work, not redoing it. I added another link in the OP.

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

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.

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.

I think I've found a way to combine hashcoin's method for Instant TX for established business relationships and Gavin's more recent ideas for Off-the-chain transactions 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, 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 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.