Good morning Subhra,
The paper does not describe how Lightning works today, so I was confused.
It seems to claim to have a constant *lock time*, but still a decrementing
*amount*, across the entire payment attempt.
In any case: any offchain updateable cryptocurrency system can host any
contract that the hosting cryptocurrency system can host, including instances
of itself.
To be a little clear, here is how I view a class hierarchy of cryptocurrency
systems.
abstract class CryptocurrencySystem { ... };
final class Blockchain : public CryptocurrencySystem {
public:
/* A blockchain requires the laws of physics in order to work. */
Blockchain(LawsOfPhysics);
...
};
abstract class OffchainCryptocurrencySystem : public CryptocurrencySystem {
public:
/* An offchain cryptocurrency system requires a pre-existing
* cryptocurrency system in order to work.
*/
OffchainCryptocurrencySystem(CryptocurrencySystem);
...
};
final class PoonDryja : public OffchainCryptocurrencySystem {
public:
/* The Lightning Network Poon-Dryja mechanism is an offchain
* cryptocurrency system.
*/
PoonDryja(CryptocurrencySystem host) :
OffchainCryptocurrencySystem(host) { ... }
...
};
Of note is that the construction of an `OffchainCryptocurrencySystem` aka
"payment channel" does *not* require a `Blockchain`!
It requires any `CryptocurrencySystem`.
While the only `CryptocurrencySystem` that needs only a real world in order to
instantiate it, is a `Blockchain`, an `OffchainCryptocurrencySystem` is itself
a `CryptocurrencySystem` that can be used to instantiate another
`OffchainCryptocurrencySystem`.
So, the base technique used by the AMCU paper is to realize that, from a
payment channel (aka `OffchainCryptocurrencySystem`) it can instantiate *two*
inner payment channels.
So something like this:
void amcu_algorithm(OffchainCryptocurrencySystem channel) {
OffchainCryptocurrencySystem subchannel1 = new
OffchainCryptocurrencySystem(channel);
OffchainCryptocurrencySystem subchannel2 = new
OffchainCryptocurrencySystem(channel);
...
}
This is doable in any offchain cryptocurrency system (though is not currently
coded in any Lightning Network implementation, because maintenance issues).
See also:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001721.html
How does it "close" a sub-channel?
Well, how do you "claim" an HTLC or "fail" an HTLC inside an existing Lightning
Network payment channel?
Basically, the participants in the offchain updateable cryptocurrency system
decide according to the rules of the protocol, in a way that is also consistent
with the rules of the hosting cryptocurrency system (in the case of LN, the
Bitcoin blockchain).
For example, in Lightning, in order to "claim" an HTLC, the participant with
the ability to claim that HTLC must present the preimage corresponding to the
hash indicated in the contract.
Then the participants check that the rules have been followed, then update the
channel state to remove the HTLC and put the money that used to be in the HTLC
into the fund of who claimed it.
Similarly, if you have a super-channel containing a sub-channel, and want to
"close" the sub-channel, what do you do?
Closing the sub-channel requires particular protocol rules to be followed,
culminating in a transaction that spends the fund of the sub-channel to
whatever set of contracts was agreed to be the latest channel state.
Then, that transaction is presented to the participants in the super-channel,
who validate that it is indeed a valid spending of the sub-channel funds, then
agree to update the channel state, removing the sub-channel funds and
re-assigning it to the outputs of the latest channel state of the sub-channel.
More concretely. suppose we have:
channel the_super_channel:
1 Bitcoin -> ZmnSCPxj
1 Bitcoin -> Subhra
2 Bitcoin -> channel the_sub_channel (ZmnSCPxj && Subhra)
channel the_sub_channel:
1 Bitcoin -> HTLC(H=ZmnSCPxj hash=XXXXX,T=Subhra timelock=615021)
1 Bitcoin -> Subhra
Then to close the inner channel, what happens is then all the participants in
the super-channel agree to update to this new state:
channel the_super_channel:
1 Bitcoin -> ZmnSCPxj
1 Bitcoin -> Subhra
1 Bitcoin -> HTLC(H=ZmnSCPxj hash=XXXXX,T=Subhra timelock=615021)
1 Bitcoin -> Subhra
(As an optimization, they could merge the two "Subhra" outputs together into a
single 2 Bitcoin output, which is what is automatically done by Lightning for
HTLC claims and fails.)
How are sub-channels created?
By whatever was agreed upon by the participants of the channel.
For example, suppose ZmnSCPxj propose to make a sub-channel of its own funds in
a new sub-channel.
Then the total state becomes:
channel the_super_channel:
1 Bitcoin -> channel the_new_sub_channel (ZmnSCPxj && Subhra)
1 Bitcoin -> Subhra
1 Bitcoin -> HTLC(H=ZmnSCPxj hash=XXXXX,T=Subhra timelock=615021)
1 Bitcoin -> Subhra
channel the_new_sub_channel:
1 Bitcoin -> ZmnSCPxj
Or, from another point-of-view: offchain updateable cryptocurrency systems
implement a cut-through mechanism.
In principle, presenting a transaction to the participants of the offchain
updateable cryptocurrency system, that can validly spend one or more outputs of
the current state of the system (and does not consume any coins outside of the
system), should be enough to convince the participants to delete those spent
outputs and replace it with the outputs of that transaction in the next state
of the offchain cryptocurrency system.
(This is not done in Lightning simply because sending smaller pieces of data
containing just the essential parts of the transactions that *would* have
fulfilled the HTLCs is cheaper than sending entire transactions through.
Not to mention having to embed a SCRIPT interpreter in our codebases would be
***HORRID***.)
And a transaction which spends some output to create a payment channel is just
another transaction that such a system can process according to the rules of
the hosting cryptocurrency system.
Similarly, a transaction which formalizes the closure of a payment channel is
just another transaction, which represents a change in the state of the
cryptocurrency system.
One might consider that cryptocurrency systems basically allow the creation and
destruction of UTXOs.
Thus, both blockchains and payment channels are cryptocurrency systems.
The difference is that blockchains allow safely storing coins held by anyone,
whereas payment channels can only safely store coins held by the participants
of the channel (because it is an n-of-n federation where *you* the user is a
member of that federation: see https://zmnscpxj.github.io/offchain/safety.html).
Conversely, I think the measuring-stick for the AMCU technique is that it
should be possible to do it onchain to implement a multi-participant CoinSwap,
because in principle a channel is just a cryptocurrency system and a blockchain
is one as well.
In any case, from a skim of the AMCU paper, it looks like all the intermediate
hops *need* to validate that all the *other* intermediate hops follow the
protocol, by presenting all the transactions involved.
This probably implies that all the intermediate hops know the entire route, and
thus who the ultimate sender and receiver are, thus utterly bad for privacy.
Hopefully my reading is wrong, or this is fixable, but if neither, it is
unlikely to be used in Lightning.
Regards,
ZmnSCPxj
> Hi ZmnSCPxj,
> It is stated in the paper "Atomic multi-channel updates with constant
> collateral in bitcoin-compatible payment-channel networks" and I am quoting
> verbatim (page 11) (last email still waiting moderator approval) "Phase I:
> Setup. The first phase requires to freeze the coins available at each channel
> involved in the protocol. Doing this naively (i.e., locking the complete
> balance in the channel at once) would lock more coins than required,
> unnecessarily increasing the collateral in the protocol. Instead, during the
> setup phase, the balance at each payment channel is split in two, effectively
> creating thereby two sub-channels: one sub-channel is set with the coins
> required for the present protocol session, while the other one is set with the
> remaining coins, which can then be freely spent. In the illustrative example
> shown in Figure 4.2, the setup phase starts with the user A collaborating
> with user B to create the transaction Tx A
> setup , where they split the 10 coins they have in the channel in two
> sub-channels: one sub-channel with 8 coins to be used in the rest of the
> protocol session and one sub-channel with the rest (i.e., 2 coins). This
> transaction is signed by both users so that it can be eventually enforced
> on-chain if required. The rest of the users behave analogously. Note that
> operations at each channel in this phase of the protocol can be carried out
> in parallel." Does this sound good ?
>
> On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar
> <subhra.mazumdar1...@gmail.com> wrote:
>
> > Hi ZmnSCPxj,
> > It is stated in the paper "Atomic multi-channel updates with
> > constant collateral in bitcoin-compatible payment-channel networks". I am
> > attaching the screenshot of the paragraph which mentions about locking the
> > amount which is required for payment transfer and not the entire channel
> > fund.
> >
> > On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote:
> >
> > > Good morning Subhra,
> > >
> > > This does not seem to make sense?
> > > For a payment that is less than the channel funds on your side, only that
> > > amount is locked behind an HTLC, and the rest remains useable for other
> > > HTLCs.
> > >
> > > What exactly are you referring to?
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > > Hi,
> > > > I was wondering when parties apply condition on fraction of
> > > > channel fund for ensuring successful payment, entire channel fund is
> > > > held. Is it possible to lock just partial amount of fund of a payment
> > > > channel and leave the rest to be used by some another payment request ?
> > > > Concept of subchannels of a single channel has been suggested in
> > > > "Atomic multi-channel updates with constant collateral in
> > > > bitcoin-compatible payment-channel networks"
> > > > https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5
> > > > but I am still in doubt what happens during closing of subchannel ?
> > > > --
> > > > Yours sincerely,
> > > > Subhra Mazumdar.
> >
> > --
> > Yours sincerely,
> > Subhra Mazumdar.
>
> --
> Yours sincerely,
> Subhra Mazumdar.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
