John Carvalho [ARCHIVE] on Nostr: š Original date posted:2022-10-15 š Original message:Erik, I am fully aware of ...
š
Original date posted:2022-10-15
š Original message: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 at 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:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221015/ff6d390f/attachment-0001.html>;
š Original message: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 at 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:
>
> https://muun.com/ (easy!)
> https://github.com/ElementsProject/lightning (reference, works well with
> core)
> https://lightning.network/ (more info)
>
>
> On Fri, Oct 14, 2022 at 11:11 AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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
>>
> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221015/ff6d390f/attachment-0001.html>;