From: Brad Morrison <bradmorrison@sonic•net>
To: Erik Aronesty <erik@q32•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Wed, 03 Jan 2024 01:11:58 -0800 [thread overview]
Message-ID: <fea6d7f6cbd7b58c052fb993e443a751@sonic.net> (raw)
In-Reply-To: <CAJowKg+sRPMqyY8pzepqc7w5ZeCdxz75_teBgsNNsta4FKeR1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
Erik/all,
Are you saying that node capacity is the primary technical limiting
factor to increasing adoption of bitcoin payments?
UBER & Lyft payments are actually poor examples because they are not
regular/monthly and I should not have used them (unless refilling
existing accounts, like gift cards). But utility bills would be a much
better example of an opportunity for bitcoin payments to compete with
existing credit card payment systems because processing timing has the
potential to be less urgent.
Sharing UTXOs seems pretty minor compared to lowering transaction costs.
Brad
On 2024-01-01 08:08, Erik Aronesty wrote:
>> .
>>
>> In the USA, where I am, large businesses like UBER, Lyft, and many major telecom, cable, & electric utilities process huge volumes of regular and irregular credit card payments on a monthly basis. Almost none oft hose transactions are completed in bitcoin.
>
> Unfortunately block size is not the limiting factor
>
> Main chain transactions have to be broadcast and stored on every node in the network which, as you know, cannot scale to the level of Uber payments
>
> Lighting and possibly ark are solutions to this problem
>
> Both require covenant tech of some kind to scale properly (nonrecursive is fine)
>
> Covenant tech (any will do, arguing about which is bike shedding at this point) allows people to share utxos and yet still maintain sovereignty over their assets
>
>>
[-- Attachment #2: Type: text/html, Size: 2695 bytes --]
next prev parent reply other threads:[~2024-01-03 9:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 12:44 Robert Dickinson
2023-01-27 12:58 ` rot13maxi
2023-01-28 10:58 ` alicexbt
2023-01-29 10:34 ` Robert Dickinson
2023-01-31 8:58 ` Erik Aronesty
2023-01-27 13:21 ` Andrew Poelstra
2023-01-27 15:43 ` Aymeric Vitte
2023-01-28 16:47 ` Aymeric Vitte
2023-01-28 4:26 ` Robert Dickinson
2023-12-29 12:27 ` Greg Tonoski
2023-12-29 19:01 ` Nagaev Boris
2023-12-30 9:58 ` Erik Aronesty
2024-01-01 13:33 ` Brad Morrison
2024-01-01 16:08 ` Erik Aronesty
2024-01-03 9:11 ` Brad Morrison [this message]
2024-01-03 13:05 ` Erik Aronesty
2023-02-03 19:56 ` Melvin Carvalho
2023-02-04 14:25 ` Kostas Karasavvas
2023-02-06 16:39 ` Erik Aronesty
2023-02-06 17:31 ` Claus Ehrenberg
2023-02-06 18:05 ` Erik Aronesty
2023-02-07 12:17 ` Aymeric Vitte
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=fea6d7f6cbd7b58c052fb993e443a751@sonic.net \
--to=bradmorrison@sonic$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
/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