Bitcoin Forum
July 19, 2018, 11:43:46 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bi-directional micro payment channels with single party bitcoin locking?  (Read 1783 times)
Meher
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
October 07, 2014, 12:13:11 PM
 #1

Mike Hearn's initial wiki article for Micropayment channels is unidirectional, i.e. the payment can flow only from one party to another and not in the reverse direction.

Example 7, https://en.bitcoin.it/wiki/Contracts

Is there a protocol that allows micropayments to flow in both directions? The solution of creating 2 channels with Bitcoins locked up by both parties is obviously valid, and I am looking for something different.

Is there a way by which, only one party locks up bitcoins, opens up a channel with another party, and the micropayments can flow in both directions?
1532043826
Hero Member
*
Offline Offline

Posts: 1532043826

View Profile Personal Message (Offline)

Ignore
1532043826
Reply with quote  #2

1532043826
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1532043826
Hero Member
*
Offline Offline

Posts: 1532043826

View Profile Personal Message (Offline)

Ignore
1532043826
Reply with quote  #2

1532043826
Report to moderator
1532043826
Hero Member
*
Offline Offline

Posts: 1532043826

View Profile Personal Message (Offline)

Ignore
1532043826
Reply with quote  #2

1532043826
Report to moderator
1532043826
Hero Member
*
Offline Offline

Posts: 1532043826

View Profile Personal Message (Offline)

Ignore
1532043826
Reply with quote  #2

1532043826
Report to moderator
h4xx0r
Full Member
***
Offline Offline

Activity: 154
Merit: 100

★Bitin.io★ - Instant Exchange


View Profile
October 07, 2014, 12:43:19 PM
 #2

Mike Hearn's initial wiki article for Micropayment channels is unidirectional, i.e. the payment can flow only from one party to another and not in the reverse direction.

Example 7, https://en.bitcoin.it/wiki/Contracts

Is there a protocol that allows micropayments to flow in both directions? The solution of creating 2 channels with Bitcoins locked up by both parties is obviously valid, and I am looking for something different.

Is there a way by which, only one party locks up bitcoins, opens up a channel with another party, and the micropayments can flow in both directions?

Well, something like the websocket protocol could be used. It's a bidirectional communication protocol on top of tcp/ip.

blueadept
Full Member
***
Offline Offline

Activity: 225
Merit: 100


View Profile
October 08, 2014, 01:45:05 PM
 #3

Check out the GitHub repo in my signature. It's very experimental at this time but the concept is there.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
cjp
Full Member
***
Offline Offline

Activity: 210
Merit: 100



View Profile WWW
October 11, 2014, 01:02:35 PM
 #4

Check out the GitHub repo in my signature. It's very experimental at this time but the concept is there.

Also check out my project:
https://github.com/cornwarecjp/amiko-pay

@blueadept:
Nice to see you made some progress too. Also nice to see we started at opposite ends of solving this problem, so there's probably a minimum of duplicated work. My Ripple-style network implementation allows for plugging in several different kinds of channel protection mechanisms, so it's probably possible to plug in your solution into my software.

How did you manage to make the channel securely bi-directional without transaction replacement? As the Wiki explains, the solution without transaction replacement is only secure in a single direction.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
Meher
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
October 13, 2014, 01:01:34 PM
 #5

Thanks cjp and blueadapt, your ideas look really cool. I will get into them and get back. Thanks!
blueadept
Full Member
***
Offline Offline

Activity: 225
Merit: 100


View Profile
October 13, 2014, 01:43:40 PM
 #6

How did you manage to make the channel securely bi-directional without transaction replacement? As the Wiki explains, the solution without transaction replacement is only secure in a single direction.

I rely on nLockTime and fees to switch directions. Basically, when you're going in one direction, the payee always has the incentive to broadcast the most recent refund transaction version and have it committed to the blockchain.

To switch directions, the nLockTime of the new refund version should be earlier. That way, the more recent version of the refund transaction is valid for inclusion in the blockchain first. I'd also increase the transaction fee in order to incent miners to include the newer version of a transaction over an earlier version for additional safety (in case the nLockTime difference between the versions is too small for the newest to be included by the time the second newest is valid).

I ended up presenting this concept Friday night in San Francisco. I think there will be a video put up; I'll link to it when it is.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
cjp
Full Member
***
Offline Offline

Activity: 210
Merit: 100



View Profile WWW
October 13, 2014, 06:40:48 PM
 #7

I rely on nLockTime and fees to switch directions. Basically, when you're going in one direction, the payee always has the incentive to broadcast the most recent refund transaction version and have it committed to the blockchain.

To switch directions, the nLockTime of the new refund version should be earlier. That way, the more recent version of the refund transaction is valid for inclusion in the blockchain first. I'd also increase the transaction fee in order to incent miners to include the newer version of a transaction over an earlier version for additional safety (in case the nLockTime difference between the versions is too small for the newest to be included by the time the second newest is valid).

I ended up presenting this concept Friday night in San Francisco. I think there will be a video put up; I'll link to it when it is.

Thanks; that sounds really useful. In fact, in the development of Amiko Pay, I'm exactly at the point where I should be integrating my multi-signature implementation into a payment link, so this comes exactly at the right moment.

I remember we discussed these things before in other threads; I think back then I criticized your ideas for having flaws. The way I see it now, this does exactly what it promises - provide a secure bi-directional channel - assumed that, around nLockTime, both parties are online to publish their transaction. Optionally, this "transaction publishing" can be delegated to a cloud provider, of course.

This does not completely eliminate the need for direct-neighbor trust in the Amiko network, but the way I see it now, that is impossible anyway with the current capabilities of Bitcoin. So, I'll continue developing my prototype for as far as is possible now, and then we'll see how to continue from there.

Donate to: 1KNgGhVJx4yKupWicMenyg6SLoS68nA6S8
http://cornwarecjp.github.io/amiko-pay/
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!