Subject: [Ledger] Question on Ledger and Sidechains

From: Alexander Pelov <[email-masked]>
Date: Wed, 17 Aug 2016 15:18:23 +0200

Dear all,

I was unable to attend the BoF, so please excuse me if the question I’d like to address has been discussed (it was not in the minutes). 

How does the concept of Interchain relate to Sidechains, e.g. as the ones introduced in https://www.blockstream.com/sidechains.pdf ?

Is there any convergence? Possibly using Interchains to enable Sidechains?

Best,
Alexander

---

From: Evan Schwartz <[email-masked]>
Date: Wed, 17 Aug 2016 15:32:48 +0200

Hi Alexander,

Sidechains is a method for making new versions of the Bitcoin blockchain
where the value of the token on the new chain is pegged to the value of
Bitcoin. The primary purpose is enabling new features to be developed for
Bitcoin more easily. In theory some of the ideas from the paper could be
used to transfer other types of assets between ledgers but it depends on a
fairly deep integration between the ledgers (the core concept is that one
blockchain is able to verify the state of the other).

Interledger is an attempt at developing the most minimal protocol you would
need to enable assets to be transferred across any type of ledger
(blockchains and central ledgers alike) using cryptographic holds and third
party "connectors". You probably could use Interledger to create a two-way
peg between two blockchains but thus far we've been thinking more about
creating competitive markets with variable exchange rates between ledgers.

Best,
Evan

On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov <[email-masked]> wrote:

> Dear all,
>
> I was unable to attend the BoF, so please excuse me if the question I’d
> like to address has been discussed (it was not in the minutes).
>
> How does the concept of Interchain relate to Sidechains, e.g. as the ones
> introduced in https://www.blockstream.com/sidechains.pdf ?
>
> _______________________________________________
> Ledger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledger
>

-- 
Evan Schwartz | Software Architect | Ripple
 <http://ripple.com>

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 17 Aug 2016 16:01:18 +0200

Hi Evan,

Thanks for the explanation!

I’d imagine that the principles behind the pegging to Bitcoin can be extended to many of the blockchains, and in some way, it seems to me the « connectors » play the role of intermediary to such « pegging ». 

Do you expect to have many inter-AS routing? Wouldn’t it be simpler for a « connector » provider to provide connectors between several ledgers, thus requiring one-hop only conversion? (this question is of course purely hypothetical). Can we expect to have any-to-bitcoin, and then have in the worst case a two-hop conversion?

A think that I’m not clear about is what happens with fluctuating exchange rates? Do you expect something RSVP-like to try to guarantee some level of consistency? For example, a seller would request 100 a-coins, and if I have a 2-route hop, it may take time until the two transfers are complete.. so, I’m not going to be sure if I need to send 1 b-coin, or 1.02 b-coins.. 

Best,
Alexander

> Le 17 août 2016 à 15:32, Evan Schwartz <[email-masked]> a écrit :
> 
> Hi Alexander,
> 
> Sidechains is a method for making new versions of the Bitcoin blockchain where the value of the token on the new chain is pegged to the value of Bitcoin. The primary purpose is enabling new features to be developed for Bitcoin more easily. In theory some of the ideas from the paper could be used to transfer other types of assets between ledgers but it depends on a fairly deep integration between the ledgers (the core concept is that one blockchain is able to verify the state of the other).
> 
> Interledger is an attempt at developing the most minimal protocol you would need to enable assets to be transferred across any type of ledger (blockchains and central ledgers alike) using cryptographic holds and third party "connectors". You probably could use Interledger to create a two-way peg between two blockchains but thus far we've been thinking more about creating competitive markets with variable exchange rates between ledgers.
> 
> Best,
> Evan
> 
> On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov <[email-masked] <mailto:[email-masked]>> wrote:
> Dear all,
> 
> How does the concept of Interchain relate to Sidechains, e.g. as the ones introduced in https://www.blockstream.com/sidechains.pdf <https://www.blockstream.com/sidechains.pdf> ?
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ledger <https://www.ietf.org/mailman/listinfo/ledger>
> 
> 
> 
> -- 
>  <http://ripple.com/>_______________________________________________
> Ledger mailing list
> [email-masked]

---

From: Evan Schwartz <[email-masked]>
Date: Wed, 17 Aug 2016 16:15:30 +0200

The trade-off is that with sidechains you don't need any intermediary
(because the ledgers understand one another) whereas with interledger you
have an intermediary (that you don't need to trust because of the
cryptographic holds) but you don't need the ledgers to be aware of one
another at all.

It might be simpler for one connector to make all the markets for all the
ledgers but it wouldn't be very competitive unless inter-AS routing were
the default. I don't think most people would be super happy with one
company getting all the FX profits in the entire world.

When the sender of a payment puts funds on hold the amount is fixed. The
connector can either forward the payment or reject it if the rate has
changed too much. In general though connectors have an incentive to appear
reliable so they would likely build in some buffer to handle fluctuations
and/or honor quotes that are a few seconds old even if the rate has changed
a bit.

On Aug 17, 2016 4:01 PM, "Alexander Pelov" <[email-masked]> wrote:

> I’d imagine that the principles behind the pegging to Bitcoin can be
> extended to many of the blockchains, and in some way, it seems to me the
> « connectors » play the role of intermediary to such « pegging ».
>
> Do you expect to have many inter-AS routing? Wouldn’t it be simpler for a
> « connector » provider to provide connectors between several ledgers, thus
> requiring one-hop only conversion? (this question is of course purely
> hypothetical). Can we expect to have any-to-bitcoin, and then have in the
> worst case a two-hop conversion?
>
> A think that I’m not clear about is what happens with fluctuating exchange
> rates? Do you expect something RSVP-like to try to guarantee some level of
> consistency? For example, a seller would request 100 a-coins, and if I have
> a 2-route hop, it may take time until the two transfers are complete.. so,
> I’m not going to be sure if I need to send 1 b-coin, or 1.02 b-coins..
>
> Best,
> Alexander
>
>
>
> Interledger is an attempt at developing the most minimal protocol you
> would need to enable assets to be transferred across any type of ledger
>  <http://ripple.com/>

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 17 Aug 2016 16:56:27 +0200

Dear Evan,

> Le 17 août 2016 à 16:15, Evan Schwartz <[email-masked]> a écrit :
> 
> The trade-off is that with sidechains you don't need any intermediary (because the ledgers understand one another) whereas with interledger you have an intermediary (that you don't need to trust because of the cryptographic holds) but you don't need the ledgers to be aware of one another at all.
> 
> It might be simpler for one connector to make all the markets for all the ledgers but it wouldn't be very competitive unless inter-AS routing were the default. I don't think most people would be super happy with one company getting all the FX profits in the entire world.
> 
As long as it’s cheap :) Otherwise, there could be competition for all one-hop clearings. 

I like the idea of having a standard way of querying the possible routes and understanding the fees, then having the holds, even over one-hop. Imagine that you have 5 big clearing companies which cover all ledgers, and 30 smaller ones, that may have only partial ledger coverage.. My worst-case fee is the min. of the fees of the 5 big clearing houses. 
> When the sender of a payment puts funds on hold the amount is fixed. The connector can either forward the payment or reject it if the rate has changed too much. In general though connectors have an incentive to appear reliable so they would likely build in some buffer to handle fluctuations and/or honor quotes that are a few seconds old even if the rate has changed a bit.
> 
If you have a one-hop transaction this would work. Then, it will all depend on the time it takes for a transaction to be confirmed, and the definition of what « changed a bit » is. If I remember correctly, it takes about an hour to have a transaction in BitCoin. So, if you do an A -> bitcoin -> B transaction, you’ll have your money locked in the bitcoin for at least an hour. During this time the fluctuations should be accepted by the (bitcoin -> B) connector. If you add another hop, things could get even more unstable. And if any of the connectors rejects the transaction, then the money on hold may actually not be redeemable anymore (or at least, we should trust the connectors). 

Maybe for the majority of the cases this would work. The users will tell…

In the protocol you are envisioning, is there a mechanism to include information in the transaction, which sais: this is the route (A->B->C), I’m using connectors AB and BC, I initiated the transaction at time X, and at that time the exchange rate was 1:1.1 A->B, and 1.1:1 for B:C. For the time X, AB takes fee of 0.001, and BC takes fee of 0.100 per transaction. Thus, I, as a sender, know exactly how much A-coins I need to send in order to get 100 B-coins (and pay the fees). 

This, however, should be binding for the BC connector in some way. Maybe announce this in the BGP routes, so I as a seller can decide if I prefer a one-hop, single-player, or a multi-hop, stable connectors, or a multi-hop, shoot-and-pray connector (with possibly much lower fee).

And yet again, it all depends on the use-case and the real demand. Not sure the goal is to build an overly complex protocol which no-one will use.

Best,
Alexander

> On Aug 17, 2016 4:01 PM, "Alexander Pelov" <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Evan,
> 
>> Le 17 août 2016 à 15:32, Evan Schwartz <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi Alexander,
>>

---

From: Evan Schwartz <[email-masked]>
Date: Thu, 18 Aug 2016 15:47:10 +0200

>
> I like the idea of having a standard way of querying the possible routes
> and understanding the fees, then having the holds, even over one-hop

Me too :)

Regarding holding funds. You're right that the longer you hold funds
(either because of multiple hops or because of slow ledgers), the more the
connectors will need to account for price volatility in their fees. I would
expect this to create quite an incentive to make ledgers more performant.
This could be accomplished either by upgrading the ledger or by using
payment channels like the Lightning <http://lightning.network> team is
working on to increase the speed of sending payments over a specific ledger.

Regarding carrying rate information with the payment. There's actually an
easier way to ensure that connectors deliver the correct amount of money.
The interledger packet has two key pieces of information: address and
amount. The amount is the amount that must be delivered to the recipient.
The source amount is set when the sender puts the first transfer (with a
fixed amount) on hold. Each connector may pass on however much money they
choose. However, if each connector (or even one) takes too much, the
recipient will get a notification for a held transfer that has less money
than the packet stipulates. They would refuse to produce the condition
fulfillment, so all of the transfers would be rolled back. If this happens
a lot with a particular connector you'd want to choose a different one.
Now, the obvious question is what happens if someone tampers with the
packet? The Interledger Payment Request
<https://github.com/interledger/rfcs/blob/master/0011-interledger-payment-request/0011-interledger-payment-request.md>
spec provides a recommendation for how recipients can use a MAC of the
packet details in the condition so the condition serves as an integrity
check as well.

There's a chance we will end up seeing different connectors offering
different QoS, but I think building it in at this point would be premature
optimization.

Not sure the goal is to build an overly complex protocol which no-one will
> use.

Definitely hoping to avoid that.

On Wed, Aug 17, 2016 at 4:56 PM, Alexander Pelov <[email-masked]> wrote:

> I like the idea of having a standard way of querying the possible routes
> and understanding the fees, then having the holds, even over one-hop.
> Imagine that you have 5 big clearing companies which cover all ledgers, and
> 30 smaller ones, that may have only partial ledger coverage.. My worst-case
> fee is the min. of the fees of the 5 big clearing houses.
>
> If you have a one-hop transaction this would work. Then, it will all
> depend on the time it takes for a transaction to be confirmed, and the
> definition of what « changed a bit » is. If I remember correctly, it takes
> about an hour to have a transaction in BitCoin. So, if you do an A ->
> bitcoin -> B transaction, you’ll have your money locked in the bitcoin for
> at least an hour. During this time the fluctuations should be accepted by
> the (bitcoin -> B) connector. If you add another hop, things could get even
> more unstable. And if any of the connectors rejects the transaction, then
> the money on hold may actually not be redeemable anymore (or at least, we
> should trust the connectors).
>
> In the protocol you are envisioning, is there a mechanism to include
> information in the transaction, which sais: this is the route (A->B->C),
> I’m using connectors AB and BC, I initiated the transaction at time X, and
> at that time the exchange rate was 1:1.1 A->B, and 1.1:1 for B:C. For the
> time X, AB takes fee of 0.001, and BC takes fee of 0.100 per transaction.
> Thus, I, as a sender, know exactly how much A-coins I need to send in order
> to get 100 B-coins (and pay the fees).
>
> This, however, should be binding for the BC connector in some way. Maybe
> announce this in the BGP routes, so I as a seller can decide if I prefer a
> one-hop, single-player, or a multi-hop, stable connectors, or a multi-hop,
> shoot-and-pray connector (with possibly much lower fee).
>
>
> And yet again, it all depends on the use-case and the real demand. Not
> sure the goal is to build an overly complex protocol which no-one will use.
>
> Best,
> Alexander
>
>
>
>
>> A think that I’m not clear about is what happens with fluctuating
>> exchange rates? Do you expect something RSVP-like to try to guarantee some
>> level of consistency? For example, a seller would request 100 a-coins, and
>> if I have a 2-route hop, it may take time until the two transfers are
>> complete.. so, I’m not going to be sure if I need to send 1 b-coin, or 1.02
>> b-coins..
>>
>> Best,
>> Alexander
>>
>>
>>
>>> How does the concept of Interchain relate to Sidechains, e.g. as the
>>> ones introduced in https://www.blockstream.com/sidechains.pdf ?
>>>