path: root/86/93c7d5e0f6f772d46b8f439fa3506f5a195587

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B11A0C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jan 2024 13:05:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 77DD641712
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jan 2024 13:05:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 77DD641712
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com
 header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256
 header.s=20230601 header.b=jlZBubEh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CVm4XLBFYYJ4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jan 2024 13:05:56 +0000 (UTC)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com
 [IPv6:2607:f8b0:4864:20::b36])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 00C2440A5B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Jan 2024 13:05:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 00C2440A5B
Received: by mail-yb1-xb36.google.com with SMTP id
 3f1490d57ef6-dbdf8d28b32so455082276.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 03 Jan 2024 05:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1704287155; x=1704891955;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=+kznsCTy3Vro9QVg/kL9UvbPsupzPNBegBEAcG+6NQA=;
 b=jlZBubEh8qbRvglMRowijBlYE7ZZMfuFkSE7CmCTgkq9+n/RZFDLGkCMArpW5jM929
 YBc1+AYSYdpeEPLKBoRYJPsH1HMZra6lo0Z9ttK17uI7IhAv0VeOkRrk7HM4YtUj0Grr
 hkNR433/n5M/thc0GwFDoqiVqhah6zUegvMJFGf/469cRRzch/xmjGxZJHXAJaidHtbk
 vJzbt78HPnaMlWXN1nDCBnEsDiIIxYarLlbR00QCL9YlGa5vEdEESHAebEoVtATWOQsj
 cQBMGrE4FUarG4GwmOY+4TSrFDZjaDGD33cuG1NqjNS8iXoXim7N3hC3s8L1igZhrmx1
 cYjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1704287155; x=1704891955;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=+kznsCTy3Vro9QVg/kL9UvbPsupzPNBegBEAcG+6NQA=;
 b=hOV3AYqycwv17LWE0ryq+3GpCKGkmeme/apyQFhkSiprXlA5VWbyIdUpSATaZ3chHv
 kQo4/WAPDN2dvzFzROnuQrsCnw0Se2R2J7mPk2pKy46GW2BAYvzfp/ZDs/+7ucLKeMfa
 33lScJbL+E8SbB4kOAmPg5ls7YO/rUEPh46TptsTp4CGAyO9CLI6xn+M1g6MAm9iuTCU
 n+LeZ9kAZU+qU0v7efjotpZc5xuSJqzEM4dWtDiEaH1Z8Nyo5XxeokRUcpdIJL8l6uhS
 qwVRVsJaznYaALyeCxqjKw8Y+nVWb5tpUt3IQy6GnOJoV3w+pFkjNJ4Lhvv6N0Vd7Vq5
 af8Q==
X-Gm-Message-State: AOJu0YyjlMJoe+3UXXDHBCh581+jV/ghY+82WnkLuQD/LgxzoqVVKzYn
 2WcrirkdjYd97AwFbxTucB8usz6e5Q8IXUU6naXr5rc=
X-Google-Smtp-Source: AGHT+IE7AQxNqobmqLzt925yClITuSo+21O0gP7Ia9ML3dgO2QmlRPru25OX1/DO35RHEj/IsLQ/maIKWTfm5WH2OAc=
X-Received: by 2002:a25:d050:0:b0:dbd:6194:60ff with SMTP id
 h77-20020a25d050000000b00dbd619460ffmr15726709ybg.2.1704287154741; Wed, 03
 Jan 2024 05:05:54 -0800 (PST)
MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <Y9PPvBiWOXpBefmD@camus> <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
 <CAJowKgJ8n0GFj3S88qW+rk2RcLg-1JH9aL22YtTB-55EEQzsYw@mail.gmail.com>
 <bda67a7ba6432b080d9c45e15cb80372@sonic.net>
 <CAJowKg+sRPMqyY8pzepqc7w5ZeCdxz75_teBgsNNsta4FKeR1g@mail.gmail.com>
 <fea6d7f6cbd7b58c052fb993e443a751@sonic.net>
In-Reply-To: <fea6d7f6cbd7b58c052fb993e443a751@sonic.net>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 3 Jan 2024 08:05:42 -0500
Message-ID: <CAJowKg+Sq+VK-K6gdHFLFt3zM8XL0xGDc=PF-jG88neadTiDqg@mail.gmail.com>
To: Brad Morrison <bradmorrison@sonic.net>
Content-Type: multipart/alternative; boundary="0000000000007427e2060e0a461e"
X-Mailman-Approved-At: Wed, 03 Jan 2024 16:20:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jan 2024 13:05:57 -0000

--0000000000007427e2060e0a461e
Content-Type: text/plain; charset="UTF-8"

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
>
>
>
>
>
>>
>>

--0000000000007427e2060e0a461e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Onchain capacity is a red herring.=C2=A0 There are so man=
y problems with it and we don&#39;t need to go into it here if it&#39;s alr=
eady been beaten to death.<div dir=3D"auto"><br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">=C2=A0What we need are the op codes necessary to c=
reate a trustless, disconnected graph of layer two solution.<div dir=3D"aut=
o"><br></div><div dir=3D"auto">We all know that some form of covenant techn=
ology is the right way to do this</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Some way of revokably sharing UTXOs, such that the incentives kee=
p coordinators in line</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
hat can get us to global scale on a layer two that isn&#39;t custodial</div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Wed, Jan 3, 2024, 4:12 AM Brad Morrison &lt;<a=
 href=3D"mailto:bradmorrison@sonic.net">bradmorrison@sonic.net</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"font-size:10pt">
<p>Erik/all, </p>
<p>Are you saying that node capacity is the primary technical limiting fact=
or to increasing adoption of bitcoin payments?</p>
<p>UBER &amp; 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 examp=
le of an opportunity for bitcoin payments to compete with existing credit c=
ard payment systems because processing timing has the potential to be less =
urgent.</p>
<p>Sharing UTXOs seems pretty minor compared to lowering transaction costs.=
</p>
<p>Brad</p>
<div>=C2=A0</div>
<p><br></p>
<p>On 2024-01-01 08:08, Erik Aronesty wrote:</p>
<blockquote type=3D"cite" style=3D"padding:0 0.4em;border-left:#1010ff 2px =
solid;margin:0">
<div dir=3D"auto">
<div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div style=3D"font-size:10pt">
<p>.</p>
<p>In the USA, where I am, large businesses like UBER, Lyft, and many major=
 telecom, cable, &amp; electric utilities process huge volumes of regular a=
nd irregular credit card payments on a monthly basis. Almost none oft hose =
transactions are completed in bitcoin.</p>
</div>
</blockquote>
</div>
</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Unfortunately block size is not the limiting factor</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Main chain transactions have to be broadcast and stored o=
n every node in the network which, as you know, cannot scale to the level o=
f Uber payments</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Lighting and possibly ark are solutions to this problem</=
div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Both require covenant tech of some kind to scale properly=
 (nonrecursive is fine)</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">Covenant tech (any will do, arguing about which is bike s=
hedding at this point) allows people to share utxos and yet still maintain =
sovereignty over their assets</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">=C2=A0</div>
<div dir=3D"auto">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div style=3D"font-size:10pt">
<p><br></p>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div>

--0000000000007427e2060e0a461e--