Pages:
Author

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

donator
Activity: 2058
Merit: 1054
You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.
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.
legendary
Activity: 1708
Merit: 1010
You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.
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.
donator
Activity: 2058
Merit: 1054
You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.
To me it looks identical to hashcoin's, what am I missing?
sr. member
Activity: 269
Merit: 250
You should rely on Mike Hearn's proposal.  As far as I know it's the one that already partially implemented.

To do this, a protocol similar to one proposed by hashcoin can be used:

  • Request a public key from the access point.
  • Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.
  • Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).
  • Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.
  • Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.
  • Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).

This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.

The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user double-spends the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.

from etotheipi in mailing:
On 04/26/2012 01:30 PM, Peter Todd wrote:
>
>> More difficulty shortens the safe time we can transact large volumes in,
>> which is good for the network.
>>
>> I'm not sure of the current implementation of replacement transactions, can
>> anyone on the core team speak to this? Can I replace transactions, or is
>> that part of the spec unimplemented or deprecated right now?
> My understanding is it's completely disabled.

Went on a scavenger hunt with Gavin a couple weeks concerning tx
replacement.  The conclusion was that if,
(1) Transaction has lock-time in the future  AND
(2) Transaction has non-maximum sequence number

Then the transaction will both propagate and be accepted into nodes'
memory pools, but will not go into any block until locktime expires.  If
the lock-time is in the past OR sequence number on all TxIns is
0xffffffff, then it will be immediately valid and included in the
blockchain.

But the actual "replacement" mechanism is disabled.  Therefore, the
nodes accept the tx as if it's replaceable, but don't allow it to be
replaced.  This means that it is effectively replaceable *once*, but
only if you inject a final transaction into the blockchain.   You can't
broadcast a final version of the same tx, because it will conflict with
the non-final one sitting in all the other nodes' memory pools.  You
need a miner to agree to remove the non-final tx from their memory pool
and specifically include your replacement.

-Alan
legendary
Activity: 1708
Merit: 1010
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.

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.
legendary
Activity: 1708
Merit: 1010
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.

But the use case that we are examing here is comparable to one or more paypal-like services.  So the comparisons are valid.
newbie
Activity: 27
Merit: 0
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.
legendary
Activity: 3066
Merit: 1147
The revolution will be monetized!
That's an awesome idea Meni! This does open up new markets that won't tolerate delays.
administrator
Activity: 5222
Merit: 13032
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.
donator
Activity: 2058
Merit: 1054
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.
Without a channel, he loses the ability to make instant payments which are larger than the deposit.

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?
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.

Quote
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.
Which covers the use case of 99% of all Paypal members, which was my point.
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.
legendary
Activity: 1708
Merit: 1010
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.
Without a channel, he loses the ability to make instant payments which are larger than the deposit.

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?

Quote

 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.


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

Quote
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.

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

Quote
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.

This I can agree with.

donator
Activity: 2058
Merit: 1054
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.
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.
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.
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.

What are the friction points for this channel arrangement and how might that affect it's adoption at the micro level?
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.
sr. member
Activity: 252
Merit: 250
Inactive
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.
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.

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?
legendary
Activity: 1708
Merit: 1010
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.
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.

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.
donator
Activity: 2058
Merit: 1054
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. I'm building up on hashcoin's work, not redoing it. I added another link in the OP.
legendary
Activity: 1708
Merit: 1066
Can you explain in a bit more detail what exactly a channel is ?
(as that is where the magic seems to happen)
donator
Activity: 2058
Merit: 1054
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.
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.

 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.
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.
legendary
Activity: 1708
Merit: 1010
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.
donator
Activity: 2058
Merit: 1054
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.
Pages:
Jump to: