From: Erik Aronesty <erik@q32•com>
To: Brad Morrison <bradmorrison@sonic•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Wed, 3 Jan 2024 08:05:42 -0500 [thread overview]
Message-ID: <CAJowKg+Sq+VK-K6gdHFLFt3zM8XL0xGDc=PF-jG88neadTiDqg@mail.gmail.com> (raw)
In-Reply-To: <fea6d7f6cbd7b58c052fb993e443a751@sonic.net>
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]
Onchain capacity is a red herring. There are so many problems with it and
we don't need to go into it here if it's already been beaten to death.
What we need are the op codes necessary to create a trustless,
disconnected graph of layer two solution.
We all know that some form of covenant technology is the right way to do
this
Some way of revokably sharing UTXOs, such that the incentives keep
coordinators in line
That can get us to global scale on a layer two that isn't custodial
On Wed, Jan 3, 2024, 4:12 AM Brad Morrison <bradmorrison@sonic•net> wrote:
> 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: 3676 bytes --]
next prev parent reply other threads:[~2024-01-03 13:05 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
2024-01-03 13:05 ` Erik Aronesty [this message]
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='CAJowKg+Sq+VK-K6gdHFLFt3zM8XL0xGDc=PF-jG88neadTiDqg@mail.gmail.com' \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bradmorrison@sonic$(echo .)net \
/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