From: Billy Tetrud <billy.tetrud@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Conjectures on solving the high interactivity issue in payment pools and channel factories
Date: Thu, 12 May 2022 12:36:25 -0500 [thread overview]
Message-ID: <CAGpPWDb-P9ubvx1iMmYR8Gm2AOwg9cbu+fCKuXHMZk2JRwW=iw@mail.gmail.com> (raw)
In-Reply-To: <mcikQmSFmiZw6Tq1GocybVcjGHNc-u9cP1aoZpJU-HEfgcqXXi1WhZSnEDMtEz3GfqAJGWpfZXjEBmsCXNSyLAgVNNcsSklERd-DJ8KeocE=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5340 bytes --]
@Antoine
> it's also hard to predict in advance the liquidity needs of the
sub-pools.
Definitely. Better than not being able to use the pool at all when
someone's offline tho.
> this fan-out transaction could interfere with the confirmation of the
simple withdraw transactions
> So there is an open question about the "honest" usage of the sub-pool
states themselves.
I don't follow this one. How would it interfere? How would it call into
question the "honesty" of the sub-pools? Why would honesty matter? I would
assume they can all be structured trustlessly.
> one could envision an accumulator committing directly to balances too
Are you suggesting that there would be some kind of opcode that operates on
this accumulator to shift around balances of some participants without
disturbing others? Sounds reasonable.
> I think the challenge is to find a compact accumulator with those
properties.
The Merkle Sum Trees like are used in Taro sound like they could probably
be useful for that.
> It's more likely a lot of them will delegate this operation to
third-party providers, with the known reductions in terms of
trust-minimizations.
There is of course that limitation. But a third party empowered only to
keep the pool functioning is much better than one given the ability to
spend on your behalf without your confirmation. This would be a big
improvement despite there still being minor privacy downsides.
> Hmmm, how could you prevent the always-online service from using the
receiving-key in "spending" mode if the balance stacked there becomes
relevant ?
You mean if your balance in the pool is 1000 sats and the service
facilitates receiving 100 sats, that service could then steal those 100
sats? And you're asking how you could prevent that? Well first of all, if
you're in a channel, not only does your service need to want to steal your
funds, but your channel partner(s) must also sign for that as well - so
they both must be malicious for these funds to be stolen. I can't see a way
to prevent that, but at least this situation prevents them from stealing
your whole 1100 sats, and can only steal 100 sats.
> see https://gitlab.com/lightning-signer/docs for wip in that direction.
Interesting. I'm glad someone's been working on this kind of thing
> A malicious pool participant could still commit her off-chain balance in
two partitions and send spends to the A&B hosting "receiving-keys" entities
without them being aware of the conflict, in the lack of a reconciliation
such as a publication space ?
Actually, I was envisioning that the always-online services holding a
receive-only key would *all* be online. So all participants of the pool
would have a representative, either one with a spending key or with just a
receiving-key (which could also be used to simply sign pool state changes
that don't negatively affect the balance of the user they represent). So
there still would be agreement among all participants on pool state
changes.
I kind of think if both techniques (sub-pools and limited-trust services)
are used, it might be able to substantially increase the ability for a pool
to operate effectively (ie substantially decrease the average downtime).
@ZmnSCPxj
> Is this not just basically channel factories?
It is.
> To reduce the disruption if any one pool participant is down, have each
sub-pool have only 2 participants each.
Yes. But the benefit of the pool over just having individual 2 person
channels is that you can change around the structure of the channels within
the pool without doing on-chain transactions. As Antoine mentioned, it may
often not be predictable which 2-person channels would be beneficial in the
future. So you want the pool to be as responsive as possible to the
changing needs of the pool.
On Tue, May 10, 2022 at 11:45 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning Billy,
>
>
> > Very interesting exploration. I think you're right that there are issues
> with the kind of partitioning you're talking about. Lightning works because
> all participants sign all offchain states (barring data loss). If a
> participant can be excluded from needing to agree to a new state, there
> must be an additional mechanism to ensure the relevant state for that
> participant isn't changed to their detriment.
> >
> > To summarize my below email, the two techniques I can think for solving
> this problem are:
> >
> > A. Create sub-pools when the whole group is live that can be used by the
> sub- pool participants later without the whole group's involvement. The
> whole group is needed to change the whole group's state (eg close or open
> sub-pools), but sub-pool states don't need to involve the whole group.
>
> Is this not just basically channel factories?
>
> To reduce the disruption if any one pool participant is down, have each
> sub-pool have only 2 participants each.
> More participants means that the probability that one of them is offline
> is higher, so you use the minimum number of participants in the sub-pool: 2.
> This makes any arbitrary sub-pool more likely to be usable.
>
> But a 2-participant pool is a channel.
> So a large multiparticipant pool with sub-pools is just a channel factory
> for a bunch of channels.
>
> I like this idea because it has good tradeoffs, so channel factories ho.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 6658 bytes --]
next prev parent reply other threads:[~2022-05-12 17:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 13:18 Antoine Riard
2022-05-01 22:53 ` Billy Tetrud
2022-05-10 0:38 ` Antoine Riard
2022-05-10 16:45 ` ZmnSCPxj
2022-05-12 17:36 ` Billy Tetrud [this message]
2023-03-17 20:54 ` jlspc
2023-04-18 3:38 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGpPWDb-P9ubvx1iMmYR8Gm2AOwg9cbu+fCKuXHMZk2JRwW=iw@mail.gmail.com' \
--to=billy.tetrud@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox