Ronan McGovern [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-02 📝 Original message: Hi folks, Danny (on the ...
📅 Original date posted:2022-02-02
📝 Original message:
Hi folks, Danny (on the TrelisDev email) and I have built out an MVP for an
invoicing tool that issues an LN invoice and then pays it out to a
merchant's BTC account.
A few things I'm looking to get input on right now. Your assistance - or
tips on people to talk to - would be greatly appreciated:
*1. Lightning to Bitcoin Cash-out*
The reason for taking this approach is that it was difficult to find a way
to support lightning to lightning payments in a non-custodial way. The
options we saw were:
1. Trampoline node (like Phoenix) - requiring management of liquidity for
our node, which is a pain (and may or may not be custodial?)
2. LN bits approach - which is custodial.
Obviously cashing LN out to BTC isn't ideal (due to LN fees + Boltz 0.5%
swap fee + Bitcoin on-chain fee), particularly because of the on-chain fee,
but at least we can do it more non-custodially.
I am interested in better technical approaches. Ideally, we'd like to
non-custodially facilitate lightning invoice generation (without the
merchant having to set up a node with a BTC pay server type approach = too
complicated for most merchants imo).
*3. Bitcoin Price Volatility*
Generally, I'm skeptical a tool like this can get a lot of adoption because
Bitcoin price right now is too volatile to be useful to customers and
merchants. I guess there is a bounty for building contracts for difference
(illegal in the US) that would support a dollar-pegged asset in lightning
channels, but I'm guessing that's 6-12 months away from being usable.
Ideas on approaches for addressing this would be appreciated.
Cheers, Ronan
~~~
P.S. I have two less technical things I'm thinking about. I know this is a
dev thread, but if anyone has reccs or folks to talk to that would be much
appreciated.
*a. Regulatory Status*
I would like to understand whether merchants making use of Trelis software
to build a payments page brings Trelis under regulation, and what options
there are for handling this in the case of:
a) just for providing the software
b) specifically with our current implementation, where the merchant uses
our api to have Boltz.exchange create a bitcoin lightning invoice that
swaps to a bitcoin payment to the merchant's wallet.
*b. Mitigating Fraud*
I am concerned both about fraudulent merchants creating payment links
*and* about
the image/brand of Trelis vis-a-vis the merchants that it serves. Broadly,
I see two extremes for the approach Trelis could take:
1) No Verification
~ in which case there is probably an adverse selection problem for the
types of merchant that would use Trelis.
2) Use Verification:
~ in which case Trelis needs to make moral judgements around what types of
businesses to support. To a degree, we already have a layer of this by
requiring login with gmail, and could progressively build on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220202/f09bf3c8/attachment.html>;
📝 Original message:
Hi folks, Danny (on the TrelisDev email) and I have built out an MVP for an
invoicing tool that issues an LN invoice and then pays it out to a
merchant's BTC account.
A few things I'm looking to get input on right now. Your assistance - or
tips on people to talk to - would be greatly appreciated:
*1. Lightning to Bitcoin Cash-out*
The reason for taking this approach is that it was difficult to find a way
to support lightning to lightning payments in a non-custodial way. The
options we saw were:
1. Trampoline node (like Phoenix) - requiring management of liquidity for
our node, which is a pain (and may or may not be custodial?)
2. LN bits approach - which is custodial.
Obviously cashing LN out to BTC isn't ideal (due to LN fees + Boltz 0.5%
swap fee + Bitcoin on-chain fee), particularly because of the on-chain fee,
but at least we can do it more non-custodially.
I am interested in better technical approaches. Ideally, we'd like to
non-custodially facilitate lightning invoice generation (without the
merchant having to set up a node with a BTC pay server type approach = too
complicated for most merchants imo).
*3. Bitcoin Price Volatility*
Generally, I'm skeptical a tool like this can get a lot of adoption because
Bitcoin price right now is too volatile to be useful to customers and
merchants. I guess there is a bounty for building contracts for difference
(illegal in the US) that would support a dollar-pegged asset in lightning
channels, but I'm guessing that's 6-12 months away from being usable.
Ideas on approaches for addressing this would be appreciated.
Cheers, Ronan
~~~
P.S. I have two less technical things I'm thinking about. I know this is a
dev thread, but if anyone has reccs or folks to talk to that would be much
appreciated.
*a. Regulatory Status*
I would like to understand whether merchants making use of Trelis software
to build a payments page brings Trelis under regulation, and what options
there are for handling this in the case of:
a) just for providing the software
b) specifically with our current implementation, where the merchant uses
our api to have Boltz.exchange create a bitcoin lightning invoice that
swaps to a bitcoin payment to the merchant's wallet.
*b. Mitigating Fraud*
I am concerned both about fraudulent merchants creating payment links
*and* about
the image/brand of Trelis vis-a-vis the merchants that it serves. Broadly,
I see two extremes for the approach Trelis could take:
1) No Verification
~ in which case there is probably an adverse selection problem for the
types of merchant that would use Trelis.
2) Use Verification:
~ in which case Trelis needs to make moral judgements around what types of
businesses to support. To a degree, we already have a layer of this by
requiring login with gmail, and could progressively build on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220202/f09bf3c8/attachment.html>;