ecurrencyhodler [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-08-13 to 2023-05-25
💬 Posted a total of 6 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:56:40

- reply

📅 Original date posted:2019-10-12
📝 Original message:
Good morning Rusty.
To add to roasbeef's point, I don't think lightningpowerusers.com is a good
indicator for market tolerance for higher fees either. It's highly
connected and does a lot of routing because Pierre has on boarded many
users through the node launcher. That means most of these users aren't
power users and therefore aren't technically skilled enough or aware of how
to find a cheaper route.
I agree with the sentiment that the network is still too young to derive
any meaningful observations around a routing fee market. This will become
clearer though as more routing tools and analytics are created for routing
node operators as well wallet users.
On Fri, Oct 11, 2019 at 6:34 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Hi Rusty,
>
> I think this change may be a bit misguided, and we should be careful about
> making sweeping changes to default values like this such as fees. I'm
> worried that this post (and the subsequent LGTMs by some developers)
> promotes the notion that somehow in Lightning, developers decide on fees
> (fees are too low, let's raise them!).
>
> IMO, there're a number of flaws in the reasoning behind this proposal:
>
> > defaults actually indicate lower reliability, and routing gets tarpitted
> > trying them all
>
> Defaults don't necessarily indicate higher/lower reliability. Issuing a
> single CLI command to raise/lower the fees on one's node doesn't magically
> make the owner of said node a _better_ routing node operator. If a node has
> many channels, with all of them poorly managed, then path finding
> algorithms
> can move extrapolate the overall reliability of a node based on failures of
> a sample of channels connected to that node. We've start to experiment with
> such an approach here, so far the results are promising[1].
>
> > There's no meaningful market signal in fees, since you can't drop much
> > below 1ppm.
>
> The market signal one should be extracting from the current state is: a
> true
> market hasn't yet emerged as routing node operators are mostly hands off
> (as
> they're used to being with their exiting bitcoin node) and have yet to
> begin
> to factor in the various costs of operating a node into their fees
> schedule.
> Only a handful of routing node operators have started to experiment with
> distinct fee settings in an attempt to feel out the level of elasticity in
> the forwarding market today (if I double by fees, by how much do my daily
> forwards and fee revenue drop off?).
>
> Ken Sedgwick had a pretty good talk on this topic as the most recent SF
> Lightning Devs meet up[2]. The talk itself unfortunately wasn't recorded,
> but there're a ton of cool graphs really digging into the various
> parameters
> in the current market. He draws a similar conclusion stating that: "Many
> current lightning channels are not charging enough fees to cover on-chain
> replacement".
>
> Developers raising the default fees (on their various implementations)
> won't
> address this as it shows that the majority of participants today (routing
> node operators) aren't yet thinking about their break even costs. IMO
> generally this is due to a lack of education, which we're working to
> address
> with our blog post series (eventually to be a fully fledged standalone
> guide) on routing node operation[3]. Tooling also needs to improve to give
> routing node operators better insight into their current level of
> performance and efficacy of their capital allocation decisions.
>
> > Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
> > and seems to have significant usage, so there clearly is market tolerance
> > for higher fees.
>
> IIRC, the fees on that node are only that high due to user error by the
> operator when setting their fees. `lnd` exposes fees on the command line
> using the fixed point numerator which some find confusing. We'll likely add
> another argument that allows users to specify their fees using their basis
> points (bps) or a plain old percentage.
>
> Independent of that, I don't think you can draw the conclusion that they
> have "significant" usage, based on solely the number of channels they have.
> That node has many channels due to the operator campaigning for users to
> open channels with them on Twitter, as they provided an easy way to package
> lnd for desktop users. A node having numerous channels doesn't necessarily
> mean that they have significant usage, as it's easy to "paint the tape"
> with
> on-chain transactions. What really matters is how effectively the node is
> managed.
>
> In terms of market signals, IMO the gradual rise of fees _above_ the
> current
> widely used default is a strong signal as it will indicate a level of
> maturation in the market. Preemptively raising defaults only adds noise as
> then the advertised fees are less indicative of the actual market
> conditions. Instead, we should (to promote a healthier network) educate
> prospective routing node operators on best practices, provide analysis
> tools t
> hey can use to make channel management and liquidity allocation decisions,
> and leave it up to the market participants to converge on steady state
> economically rational fees!
>
> [1]: https://github.com/lightningnetwork/lnd/pull/3462
> [2]:
> https://github.com/ksedgwic/lndtool/blob/graphstats/lightning-fee-market.pdf
> [3]:
> https://blog.lightning.engineering/posts/2019/08/15/routing-quide-1.html
>
>
> On Thu, Oct 10, 2019 at 7:50 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Hi all,
>>
>> I've been looking at the current lightning network fees, and it
>> shows that 2/3 are sitting on the default (1000 msat + 1 ppm).
>>
>> This has two problems:
>> 1. Low fees are now a negative signal: defaults actually indicate
>> lower reliability, and routing gets tarpitted trying them all.
>> 2. There's no meaningful market signal in fees, since you can't
>> drop much below 1ppm.
>>
>> Compare lightningpowerusers.com which charges (10000 msat + 5000 ppm),
>> and seems to have significant usage, so there clearly is market
>> tolerance for higher fees.
>>
>> I am proposing that as of next release of c-lighting, we change defaults
>> on new channels to 5000 msat + 500ppm, and I'd like the other
>> implementations to join me.
>>
>> Over time, that should move the noise floor up. I picked 500ppm because
>> that's still 1% at 20 hops, so minimally centralizing. I picked 5000
>> msat base for less quantifiable reasons.
>>
>> Here's default fee a rate table in USD (@10k per BTC):
>>
>> Amount Before After
>> 0.1c 0.0100001c 0.05005c
>> 1c 0.010001c 0.0505c
>> 10c 0.01001c 0.055c
>> $1 0.0101c 0.1c
>> $10 0.011c 0.55c
>> $100 0.02c 5.05c
>> $1000 0.11c 50.05c
>>
>> Thoughts?
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191012/a54966e1/attachment.html>

2023-06-09 12:55:55

- reply

📅 Original date posted:2019-08-14
📝 Original message:
Hi ZmnSCPxj!
Submarine swaps are a great current solution, but we still have to wait for
confirmations.
>Further, while it involves fees, it does give you control over what nodes
you make channels with, and would be a good investment in your future
accessibility over the Lightning Network.
What disadvantages do you see over this proposal and say something like
autopilot? Or do you just prefer manual channel management overall?
On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Ecurrencyhodler,
>
> A current and practical way to set up incoming liquidity would be to take
> some onchain funds, create a channel to a high-uptime node on the network
> (just run an autopilot), then use a submarine swap (i.e. pay offchain funds
> to buy onchain funds).
> Then you can reuse the same onchain funds over and over to make more
> liquidity until the submarine swap provider runs out of onchain funds or
> you have sufficient liquidity or your money has been drained by the fees
> involved.
>
> While this requires onchain funds, presumably as a new business or
> merchant you will have capital in some form before starting your business.
> The most sensible way to store and transport financial capital is, of
> course, Bitcoin, thus you already have what is needed to start this, you
> simply have to do it before you perform other operations.
> Further, while it involves fees, it does give you control over what nodes
> you make channels with, and would be a good investment in your future
> accessibility over the Lightning Network.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler Blockchains <
> ecurrencyhodler at gmail.com> wrote:
>
> > Hi. I'd like to propose a way for instant inbound liquidity to be
> automated via invoices and would appreciate your feedback. It's similar to
> Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
> >
> > Proposal: Automated Inbound Liquidity With Invoices
> >
> > For Who: Full Lightning Network nodes
> >
> > Problem: Waiting for inbound liquidity as channel establishes when you
> first come online and want to receive a LN payment.
> >
> > Solution: Embedding the node uri of the invoice creator, along with
> amount to be routed.
> >
> > Scenario:
> >
> > 1. Bob wants to send me 100,000 sats.
> > 2. My node just came online and has 0 inbound liquidity.
> > 3. I create an invoice for 100,000 sats. My LN node recognizes I have
> 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> > 5. I now own and can spend 100,000 sats instantly.
> >
> > Considerations:
> >
> > - This auto establishing of channels and pushing payments isn’t for
> all LN nodes. Just routing nodes.
> > - Bob doesn’t need to be the one to establish the channel. He can
> push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> > - Certain specifics need to be flushed out such as the size of Bob’s
> channel. Right now I think Bob can manually set the size of the channels
> to be established on his end. Should be smaller channels at first. If the
> person gets paid again, just establish another channel towards the same
> node if there isn't enough capacity.
> > - Routing nodes who provide this service can charge a premium.
> > - Bob, as a liquidity provider, won't cheat against himself so I can
> make LN payments instantly.
> > - The beauty behind this proposal is that I can receive a payment
> instantly, I can send payments instantly, and that it hides everything from
> me as an end user.
> > - Can possibly be extended to neutrino LN wallets if they are public.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/390ffc4c/attachment.html>

2023-06-09 12:55:55

- reply

📅 Original date posted:2019-08-14
📝 Original message:
>So would `push_msat`; until confirmed deeply the channel opening can still
be cancelled by double-spending and it would be foolhardy to deliver the
product until the channel is deeply confirmed to be opened.
Okay so there's 2 situations here I'd like to explore:
1. Bob -> routing node -> Me
2. Bob -> Me
*Scenario 1*
If Bob pays the invoice and the routing node opens a payment channel and
pushes sats to me, you could stipulate that the routing node isn't able to
fully take ownership of the sats until 6 confirmations potentially via Hodl
Invoices (by the time the routing nodes channel with pushed payments
confirms with mine). But I could still make LN payments instantly through
the routing node because the routing node just needs to wait until the 6
confirmations and settle all accounts after the fact.
*Scenario 2*
Bob and I know each other so if channel disappears, it's basically the same
situation with Thor's instant channel. But we could completely remove
scenario 2 and only allow routing nodes to open channels to me as long as
Bob makes the payment.
On Wed, Aug 14, 2019 at 12:03 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Ecurrencyhodler,
>
> > Hi ZmnSCPxj!
> >
> > Submarine swaps are a great current solution, but we still have to wait
> for confirmations.
>
> So would `push_msat`; until confirmed deeply the channel opening can still
> be cancelled by double-spending and it would be foolhardy to deliver the
> product until the channel is deeply confirmed to be opened.
> At least this way, you can perform the preparation in parallel to your
> other startup operations for starting your business before actual launch of
> your merchant website.
>
> >
> > >Further, while it involves fees, it does give you control over what
> nodes you make channels with, and would be a good investment in your future
> accessibility over the Lightning Network.
> >
> > What disadvantages do you see over this proposal and say something like
> autopilot? Or do you just prefer manual channel management overall?
>
> This should eventually be implementable by some kind of auto-system.
> It is still early days and a lot of infrastructure is yet to be written.
>
> Regards,
> ZmnSCPxj
>
> >
> > On Tue, Aug 13, 2019 at 6:27 PM ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
> >
> > > Good morning Ecurrencyhodler,
> > >
> > > A current and practical way to set up incoming liquidity would be to
> take some onchain funds, create a channel to a high-uptime node on the
> network (just run an autopilot), then use a submarine swap (i.e. pay
> offchain funds to buy onchain funds).
> > > Then you can reuse the same onchain funds over and over to make more
> liquidity until the submarine swap provider runs out of onchain funds or
> you have sufficient liquidity or your money has been drained by the fees
> involved.
> > >
> > > While this requires onchain funds, presumably as a new business or
> merchant you will have capital in some form before starting your business.
> > > The most sensible way to store and transport financial capital is, of
> course, Bitcoin, thus you already have what is needed to start this, you
> simply have to do it before you perform other operations.
> > > Further, while it involves fees, it does give you control over what
> nodes you make channels with, and would be a good investment in your future
> accessibility over the Lightning Network.
> > >
> > > Regards,
> > > ZmnSCPxj
> > >
> > > Sent with ProtonMail Secure Email.
> > >
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Monday, August 12, 2019 11:42 AM, Ecurrencyhodler Blockchains <
> ecurrencyhodler at gmail.com> wrote:
> > >
> > > > Hi. I'd like to propose a way for instant inbound liquidity to be
> automated via invoices and would appreciate your feedback. It's similar to
> Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
> > > >
> > > > Proposal: Automated Inbound Liquidity With Invoices
> > > >
> > > > For Who: Full Lightning Network nodes
> > > >
> > > > Problem: Waiting for inbound liquidity as channel establishes when
> you first come online and want to receive a LN payment.
> > > >
> > > > Solution: Embedding the node uri of the invoice creator, along with
> amount to be routed.
> > > >
> > > > Scenario:
> > > >
> > > > 1. Bob wants to send me 100,000 sats.
> > > > 2. My node just came online and has 0 inbound liquidity.
> > > > 3. I create an invoice for 100,000 sats. My LN node recognizes I
> have 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> > > > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> > > > 5. I now own and can spend 100,000 sats instantly.
> > > >
> > > > Considerations:
> > > >
> > > > - This auto establishing of channels and pushing payments isn’t
> for all LN nodes. Just routing nodes.
> > > > - Bob doesn’t need to be the one to establish the channel. He can
> push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> > > > - Certain specifics need to be flushed out such as the size of
> Bob’s channel. Right now I think Bob can manually set the size of the
> channels to be established on his end. Should be smaller channels at
> first. If the person gets paid again, just establish another channel
> towards the same node if there isn't enough capacity.
> > > > - Routing nodes who provide this service can charge a premium.
> > > > - Bob, as a liquidity provider, won't cheat against himself so I
> can make LN payments instantly.
> > > > - The beauty behind this proposal is that I can receive a payment
> instantly, I can send payments instantly, and that it hides everything from
> me as an end user.
> > > > - Can possibly be extended to neutrino LN wallets if they are
> public.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190814/fff0674c/attachment.html>

2023-06-09 12:55:54

- reply

📅 Original date posted:2019-08-13
📝 Original message:
Hi Hampus!
>It won't work out in the long run because if you connect say mobile
wallets this way, one mobile could be offline, which locks the funds for
the other part.
Hmm I didn't consider mobile wallets being offline for a long period of
time. That's a good point. But if smaller channels are preferred and they
are charging a premium, I wonder if the opportunity cost here would be
worth it. It's also possible to set shorter HTLC's for unilateral closures
for these specific channels.
>Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
You know I actually really like this feature of LN invoices. It's very
practical and a great stop gap. My only gripe is that it keeps the user
off the LN and they still would have to wait confirmations in order for
their BTC to be "confirmed". Automating inbound liquidity with push
payments would make it instant as well as keep users on the LN.
>Another way is to set up a "temporary" custodian channel if the receiver
doesn't have enough inbound capacity.
How it would work is that you have a third party custodian (i.e the wallet
provider) receives the money on your behalf. The next time you want to send
something, this channel takes top priority.
Yea. This is a great suggestion. And probably where things will end up
for mobile neutrino Ln wallets in the near future. But the benefits to
automating inbound liquidity with invoices is that it would be
non-custodial while offering almost the exact same experience.
On Tue, Aug 13, 2019 at 6:31 AM Hampus Sjöberg <hampus.sjoberg at gmail.com>
wrote:
> While I do agree that this is a problem that we needs to be addressed
> somehow, I don't agree on your proposal because I don't think we should
> connect two end-users this way. It won't work out in the long run because
> if you connect say mobile wallets this way, one mobile could be offline,
> which locks the funds for the other part.
>
> Another approach could be that wallets start using the already existing
> fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
> address.
> This way, the sender could send the funds on-chain should it fail to send
> over Lightning.
> This however requires the sender to have off-chain funds available which
> is probably not the case. What could be done here is a splice out or a
> submarine swap, but they are not well established yet unfortunately.
>
> Another way is to set up a "temporary" custodian channel if the receiver
> doesn't have enough inbound capacity.
> How it would work is that you have a third party custodian (i.e the wallet
> provider) receives the money on your behalf. The next time you want to send
> something, this channel takes top priority.
> This way the on-boarding process is pretty much solved, if you are OK with
> some trust.
>
> What do you think?
>
> Cheers
> Hampus
>
> Den mån 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains <
> ecurrencyhodler at gmail.com>:
>
>> Hi. I'd like to propose a way for instant inbound liquidity to be
>> automated via invoices and would appreciate your feedback. It's similar to
>> Thor's instant channel but this proposal would only be valuable if it
>> becomes a standard across all lightning implementations and wallets. It
>> won't work if it's limited to just one Lightning wallet.
>>
>> *Proposal:* Automated Inbound Liquidity With Invoices
>>
>> *For Who:* Full Lightning Network nodes
>>
>> *Problem:* Waiting for inbound liquidity as channel establishes when you
>> first come online and want to receive a LN payment.
>>
>> *Solution: *Embedding the node uri of the invoice creator, along with
>> amount to be routed.
>>
>> *Scenario: *
>>
>> 1. Bob wants to send me 100,000 sats.
>> 2. My node just came online and has 0 inbound liquidity.
>> 3. I create an invoice for 100,000 sats. My LN node recognizes I
>> have 0 inbound liquidity so my wallet also embeds my URI in the invoice.
>> 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
>> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
>> payment.
>> 5. I now own and can spend 100,000 sats instantly.
>>
>> *Considerations:*
>>
>> - This auto establishing of channels and pushing payments isn’t for
>> all LN nodes. Just routing nodes.
>> - Bob doesn’t need to be the one to establish the channel. He can
>> push the information down the line until a node dedicated to routing is
>> found. The routing node can then be the one to establish the channel with
>> me.
>> - Certain specifics need to be flushed out such as the size of Bob’s
>> channel. Right now I think Bob can manually set the size of the channels
>> to be established on his end. Should be smaller channels at first. If the
>> person gets paid again, just establish another channel towards the same
>> node if there isn't enough capacity.
>> - Routing nodes who provide this service can charge a premium.
>> - Bob, as a liquidity provider, won't cheat against himself so I can
>> make LN payments instantly.
>> - The beauty behind this proposal is that I can receive a payment
>> instantly, I can send payments instantly, and that it hides everything from
>> me as an end user.
>> - Can possibly be extended to neutrino LN wallets if they are public.
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/5a9a3fbd/attachment-0001.html>

2023-06-09 12:55:53

- reply

📅 Original date posted:2019-08-13
📝 Original message:
Hey Rusty. Thanks for your feedback.
>If you publish your node address, Bob can already get this from the
gossip network, or the DNS seed as a last resort (and I expect
implementations to start doing this: I did it manually to buy a
thelightningconference.com ticket recently, for example).
This is a good point and very cool you were able to do that for the
Lightning Conference (hopefully I'll see you there!). Perhaps another
condition should be that if I am a public node and already connected to a
node, the URI is not embedded in the invoice but instead should be gathered
via the gossip network.
But keep in mind that the intended goal of this proposal is for the end
user to have a completely automated experience from invoice payment to
payment reception without having to manage any channels.
>So this proposal is mainly useful where you have no channels at all
(thus cannot advertize your node), or don't want to publish it
generally. And in both those cases, Bob probably doesn't want a channel
with you because it wouldn't be useful for paying anyone else.
I'm not sure I agree.
All nodes who come online for the first time are not connected to any
channels. And even if I hand Bob my URI, I still have to wait for the
channels to be established before I'm able to receive payment. Bob could
open and push a payment to me but this doesn't have to be a requirement.
It could be pushed to a routing node Bob is connected to.
This would also be helpful for non-technical node managers. Rather than
going through the process of finding out a URI and trying to manage their
channels constantly by checking for inbound liquidity, they could simply
create an invoice. If inbound liquidity is lacking, the problem would be
automatically solved for them. This wouldn't be the most efficient way to
obtain inbound liquidity, I think that would only really be more important
for more advanced LN users. Especially because asking someone to open and
commit BTC to you is already a bit of a difficult relationship to negotiate
as expected amount of usage will vary.
Lastly, routing nodes are financially incentivized to do open a channel
with me because they could charge a premium. Thor's instant channel is an
example of this.
On Tue, Aug 13, 2019 at 3:59 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Ecurrencyhodler Blockchains <ecurrencyhodler at gmail.com> writes:
> > 1. Bob wants to send me 100,000 sats.
> > 2. My node just came online and has 0 inbound liquidity.
> > 3. I create an invoice for 100,000 sats. My LN node recognizes I
> have 0
> > inbound liquidity so my wallet also embeds my URI in the invoice.
> > 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When
> > it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> > payment.
> > 5. I now own and can spend 100,000 sats instantly.
>
> If you publish your node address, Bob can already get this from the
> gossip network, or the DNS seed as a last resort (and I expect
> implementations to start doing this: I did it manually to buy a
> thelightningconference.com ticket recently, for example).
>
> So this proposal is mainly useful where you have no channels at all
> (thus cannot advertize your node), or don't want to publish it
> generally. And in both those cases, Bob probably doesn't want a channel
> with you because it wouldn't be useful for paying anyone else.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/339ee04d/attachment.html>

2023-06-07 23:22:02

- reply

📅 Original date posted:2023-05-25
🗒️ Summary of this message: A discussion on the potential impact of the ARK proposal on the mempool and fees, with concerns about an increase in unconfirmed transactions.
📝 Original message:Date: Wed, 24 May 2023
From: ecurrencyhodler<ecurrencyhodler at gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
Second Layer Solution (ecurrencyhodler)
Thanks David for your write up. Clear, concise, and super understandable as
always.
It sounds like to me that ARK is using PSBT's + covenants to secure
unconfirmed txns.
I see how this significantly reduces onchain footprint. But wouldn't this
also have a massive impact at scale to the mempool filling it with
unconfirmed txns? Couple concerns I have are:
1. It would create an ever growing fee environment within the 10-minute
block. Therefore it would be possible for the first settlement txn in the
first 5 seconds to get pushed out of the mempool by later settlement txns
closer to the 10 minute mark.
2. Mempools would have to drastically increase their size to capture all
the 5-second settlement unconfirmed txns and default bitcoin core nodes
would get flooded.
Thanks again burak for your ARK proposal. There seems to be a good amount
of excitement about what this could unlock in the future which is quite
refreshing to see.
On Thu, May 25, 2023 at 5:01 AM <
bitcoin-dev-request at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Ark: An Alternative Privacy-preserving Second Layer
> Solution (adiabat)
> 2. Re: Ark: An Alternative Privacy-preserving Second Layer
> Solution (David A. Harding)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 May 2023 16:20:35 -0400
> From: adiabat <rx at awsomnet.org>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
> Second Layer Solution
> Message-ID:
> <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=
> hfwsxLgwWkUw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi - thanks for the Ark write up; I have a bunch of questions but here's 2:
>
> ---
> Q1:
> "Pool transactions are created by ark service providers perpetually
> every 5 seconds"
>
> What exactly happens every 5 seconds? From the 15.44.21-p-1080.png
> diagram [1], a pool transaction is a bitcoin transaction, with all the
> inputs coming from the ASP. My understanding is that every 5 seconds,
> we progress from PoolTx(N) to PoolTx(N+1). Does the ASP sign a new
> transaction which spends the same ASP funding inputs as the previous
> pool transaction, which is a double spend or fee bump? Or does it
> spend the outputs from the previous PoolTx?
>
> In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending
> the same inputs (call this method A), or does PoolTx(2) spend an
> output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for
> PoolTx(2) to become valid (method B)? Or are they completely separate
> transactions with unconflicting inputs (method C)?
>
> When the ASP creates a pool transaction, what do they do with it? Do
> they broadcast it to the gossip network? Or share it with other pool
> participants?
>
> With method A, if the ASP shares pool transactions with other people,
> there Doesn't seem to be any way to ensure which PoolTx gets
> confirmed, invalidating all the other ones. They're all valid so
> whichever gets into a block first wins.
>
> With method B, there seems to be a large on-chain load, with ~120
> chained transactions trying to get in every block. This wouldn't play
> nicely with mempool standardness and doesn't seem like you could ever
> "catch up".
>
> With method C, ASPs would need a pretty large number of inputs but
> could recycle them as blocks confirm. It would cost a lot but maybe
> could work.
>
> ---
> Q2:
>
> The other part I'm missing is: what prevents the ASP from taking all
> the money? Before even getting to vTXOs and connector outputs, from
> the diagram there are only ASP inputs funding the pool transaction.
> If the pool transaction is confirmed, the vTXOs are locked in place,
> since the vTXO output cannot be changed and commits to all
> "constrained outs" via OP_CTV. If the pool transaction is
> unconfirmed, the ASP can create & sign a transaction spending all ASP
> funding inputs sending the money back to the ASP, or anywhere else.
> In this case, users don't have any assurance that their vTXO can ever
> turn into a real UTXO; the ASP can "rug-pull" at any time, taking all
> the money in the pool. Adding other inputs not controlled by the ASP
> to the transaction wouldn't seem to fix the problem, because then any
> user removing their inputs would cancel the whole transaction.
>
> More detail about how these transactions work would be appreciated, thanks!
>
> -Tadge
>
> [1]
> https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 May 2023 13:02:40 -1000
> From: "David A. Harding" <dave at dtrt.org>
> To: Burak Keceli <burak at buraks.blog>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
> Second Layer Solution
> Message-ID: <3c6c3b8b562bb56bbb855dc2b2b71f78 at dtrt.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hi Burak,
>
> Thanks for this really interesting protocol! I tend to analyze
> complicated ideas like this by writing about them in my own words, so
> I've pasted my summary of your idea to the end of this email in case
> it's useful, either to other people or to you in helping understand my
> one concern.
>
> My concern is the same one I think Olaoluwa Osuntokun mentioned on
> Twitter[1] and (less clear to me) might be related to ZmnSCPxj's
> concern[2]:
>
> It seems to me that receiving a payment on the protocol, including
> conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting
> for the transaction containing that payment to confirm to a sufficient
> depth (e.g., I'd wait 6 blocks for small payments and longer for huge
> payments). Am I missing something?
>
> My summary of how I think that part of the protocol works is in the
> sections labeled "Make an unconditioned payment" and "Make a conditional
> payment" below. In short, it's clear to me how the service provider and
> the customer can make instant atomic swaps with each other---they can
> either spend instantly cooperatively, or they have to wait for a
> timeout. But how can a receiver of funds be assured that they will
> actually get those funds unless there's already a timelock and
> cooperative spend path placed on those funds?
>
> -Dave
>
> Rough initial summary of Ark protocol:
>
> Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
> new unconfirmed onchain transaction that pays three outputs (the
> three Cs):
>
> 1. *Change Output:* money not used for the other two Cs that gets sent
> back to the the transaction creator.
>
> 2. *Connector Output:* an output that will be used in a future
> transaction created by Alice as protection against double spends.
>
> 3. *Commitment Output:* a CTV-style commitment to a set of outputs that
> can be published later in a descendant transaction (alternatively,
> the commitment output may be spent unilaterally by Alice after 4
> weeks).
>
> Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT
> with an input of his and a change output. She updates the PSBT with a
> commitment output that refunds Bob the 1 BTC and a connector output with
> some minimum value. They both sign the PBST and it is broadcast. We'll
> ignore fees in our examples, both onchain transaction fees and fees paid
> to Alice.
>
> From here, there are several things that Bob can do:
>
> - *Unilaterally withdraw:* Bob can spend from the commitment output to
> put his refund onchain. The refund can only be spent after a 24-hour
> time delay, allowing Bob to optionally come to an agreement with Alice
> about how to spend the funds before Bob can spend them unilaterally
> (as we'll see in a moment). For example, the script might be[3]:
>
> pk(B) && (older(1 day) || pk(A))
>
> - *Collaboratively withdraw:* as seen above, Bob has the ability to come
> to a trustless agreement with Alice about how to spend his funds.
> They can use that ability to allow Bob to trade his (unpublished) UTXO
> for a UTXO that Alice funds and broadcasts. For example:
>
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction. This will ensure that
> any attempt by Bob to double-spend his deposit transaction will
> invalidate this withdrawal transaction, preventing Bob from being
> able to steal any of Alice's funds.
>
> Also included in Alice's unsigned PSBT is another connector
> output plus the output that pays Bob his 1 BTC.
>
> - Bob receives Alice's unsigned PSBT and creates a separate PSBT
> that includes his unpublished UTXO as an input, giving its value
> to Alice in an output. The PSBT also includes as an input the
> connector output from Alice's PSBT. This will ensure that any
> attempt by Alice to double spend her transaction paying him will
> invalidate his transaction paying her.
>
> - Bob signs his PSBT and gives it to Alice. After verifying it,
> Alice signs her PSBT and broadcasts it.
>
> - *Collaboratively trade commitments:* as mentioned, the commitment
> output that pays Bob may be claimed instead by Alice after 4 weeks, so
> Bob will need to either withdraw or obtain a new commitment within
> that
> time. To trade his existing commitment for a new commitment looks
> similar to the collaborative withdrawal procedure but without the
> creation of an immediately-spendable onchain output:
>
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction, again preventing double
> spending by Bob. Alice also includes a new connector and a new
> commitment that again allows Bob to later claim 1 BTC.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her, with the new connector again being
> included as an input to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - *Make an unconditioned payment:* using the mechanisms described above,
> it's possible to make either an onchain payment or an offchain
> payment---just have Carol receive the new output or commitment rather
> than Bob. That payment would have no conditions (except its
> atomicity).
>
> - *Make a conditional payment:* imagine that Carol knows a secret (e.g.
> a preimage) that Bob is willing to pay for.
>
> - Alice creates an unsigned PSBT depending on the connector from
> Bob's deposit transaction and creating a new connector. The PSBT
> includes an output paying Carol (either onchain or via a
> commitment) with an HTLC, allowing Carol to claim the funds if
> she
> reveals the secret or allowing Bob to claim the funds after a
> timeout.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her with the HTLC condition attached and,
> again, with connectors being used to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - Carol can settle her HTLC by either revealing the secret onchain
> or by trading her commitment containing the HTLC clause for a
> commitment from Alice that doesn't contain the clause (which
> Alice will only accept by learning the secret, since Alice has
> to settle with Bob). Alice can then either settle onchain or
> trade commitments with Bob after giving him the secret.
>
> - *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice
> can claim the funds from the commitment output (i.e., takes his
> money).
>
> If Bob did actually do something, and if every other user who also
> had an unpublished output in the commitment transaction did
> something, then they all exchanged their portion of the funds in
> this output to Alice, so Alice can now claim all of those funds
> onchain in a highly efficient manner.
>
> Regarding the connector outputs, although all of the examples above show
> Alice directly spending from the connector output in Bob's deposit
> transaction, atomicity is also ensured if Alice spends from any output
> descended from Bob's connector output. Connector outputs from different
> deposits can be used as inputs into the same transaction, merging their
> histories. This allows all operations made by Alice to be fully atomic,
> ensuring that she doesn't lose any money during a reorg of any length.
>
> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive from any
> deposit less than safe_confirmation_depth blocks.
>
> [1] https://twitter.com/roasbeef/status/1661266771784126464
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.html
>
> [3]
>
> https://min.sc/#c=pk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 96, Issue 58
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230525/45564862/attachment-0001.html>