"Elder" Payment Channels

Research
1

Posted this to https://gitter.im/grin_community/crypto earlier but posting it here for a wider audience.
Nobody there pointed out any glaring errors why this is obviously flawed so please take a look and poke some holes in it.

I will post this to the mailing list in a day or so (assuming this is not completely broken).

Edit: Received some valuable feedback from @tromp and we discussed some alternative ways to improve the original proposal.

Latest version here -

https://gist.github.com/antiochp/dfb1cb0273421584a1fcf2341da9d683

3 Likes
2

ty for the link and the invitation to be a wider audience

1 Like
3

So it appears the proposal for long chains of kernels is unpopular (and probably unworkable in practice).

2nd attempt “Elder Redux”.
This approach reuses a single “channel” output and simplifies the “revoke” step (at a cost of needing endpoint specific txs) - https://gist.github.com/antiochp/d490280fa0b87e0cd84f961b0911119f

1 Like
4

A pair of endpoint specific “close” and “settle” txs are negotiated for both Alice and Bob. Each “settle” tx has a relative lock height from the corresponding “close” tx kernel, introducing a delay between “close” and “settle” (24 hours for example

If your goal is mircopayments I don’t think this works well.

If your designing payment scheme’s, I would suggest service models, i.e. Alice has a smart phone Bob has a always on server, Alice is giving Bob a fee to handle grins downsides.

Alice and Bob lock up some money for 48 hours, but more on Alice side.

Alice tells Bob to make small payments on her behalf for 24 hours ish.

Alice’s phone when plugged in at night or fuzzy logic says it’s getting to close to 48 hours, gets in conntact with Bob, to modify the deal.