Erik, I am fully aware of Lightning and have a been a proponent and builder of it since it was launched, including getting Bitfinex to support LN, building a RN LDK implementation in our upcoming app, etc, but frankly LN has nowhere near the adoption of onchain payments for commerce, and LN complexity, reliability, maintenance and overhead are real obstacles for merchants.
One of your links is to Muun, who started this thread!
There is no practicality in a merchant saying they accept bitcoin, but not onchain, or in having many checkout and customer service versions for many bitcoin payment methods.
Merchants accepting base layer bitcoin is one if the most important types of adoption there is.
-John
On Fri, Oct 14, 2022 at 6:29 PM Erik Aronesty <
erik@q32.com> wrote:
Also, lightning works fine and is readily available in convenient mobile apps used by millions of people, or in . So the need for a 0conf has been mitigated by other solutions for fast payments with no need for a trust relationship. And for people that don't like mobile risks, core lightning and other solutions are now easily installed and configured for use in fast payments.
some references:
On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of gaslighting
> happening with the advancement of RBF somehow being okay, while merchants
> wanting to manage their own 0conf risk better being not okay.
The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
Connecting to large numbers of nodes to try to risk-manage propagation _is_ an
attack, albeit a mild one. Everyone doing that is very harmful; only a few
merchants being able to do it is very unfair/centralized.
...and of course, in the past this has lead to merchants trying to make deals
with miners directly, even going as far as to suggest reorging out
double-spends. I don't need to explain why that is obviously extremely harmful.
--
https://petertodd.org 'peter'[:-1]@petertodd.org