From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B11A0C0037 for ; 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 ; 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 ; 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 ; 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 ; 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: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com> In-Reply-To: From: Erik Aronesty Date: Wed, 3 Jan 2024 08:05:42 -0500 Message-ID: To: Brad Morrison Content-Type: multipart/alternative; boundary="0000000000007427e2060e0a461e" X-Mailman-Approved-At: Wed, 03 Jan 2024 16:20:16 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Onchain capacity is a red herring.=C2=A0 There are so man= y problems with it and we don't need to go into it here if it's alr= eady been beaten to death.

=C2=A0What we need are the op codes necessary to c= reate a trustless, disconnected graph of layer two solution.

We all know that some form of covenant techn= ology is the right way to do this

Some way of revokably sharing UTXOs, such that the incentives kee= p coordinators in line

T= hat 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> wrot= e:

Erik/all,

Are you saying that node capacity is the primary technical limiting fact= or 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 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.

Sharing UTXOs seems pretty minor compared to lowering transaction costs.=

Brad

=C2=A0


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 a= nd irregular credit card payments on a monthly basis. Almost none oft hose = transactions are completed in bitcoin.

=C2=A0
=C2=A0
Unfortunately block size is not the limiting factor
=C2=A0
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
=C2=A0
Lighting and possibly ark are solutions to this problem
=C2=A0
Both require covenant tech of some kind to scale properly= (nonrecursive is fine)
=C2=A0
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
=C2=A0
=C2=A0
=C2=A0
=C2=A0


--0000000000007427e2060e0a461e--