* [bitcoin-dev] Ordinal Inscription Size Limits
@ 2023-01-27 12:44 Robert Dickinson
2023-01-27 12:58 ` rot13maxi
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Robert Dickinson @ 2023-01-27 12:44 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
I'm curious what opinions exist and what actions might be taken by core
developers regarding storing unlimited amounts of NFT (or other?) content
as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal
scheme is elegant and genius IMHO, but when I think about the future disk
use of all unpruned nodes, I question whether unlimited storage is wise to
allow for such use cases. Wouldn't it be better to find a way to impose a
size limit similar to OP_RETURN for such inscriptions?
I think it would be useful to link a sat to a deed or other legal construct
for proof of ownership in the real world, so that real property can be
transferred on the blockchain using ordinals, but storing the property
itself on the blockchain seems nonsensical to me.
[-- Attachment #2: Type: text/html, Size: 866 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
@ 2023-01-27 12:58 ` rot13maxi
2023-01-28 10:58 ` alicexbt
2023-01-27 13:21 ` Andrew Poelstra
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: rot13maxi @ 2023-01-27 12:58 UTC (permalink / raw)
To: Robert Dickinson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
Hello,
“Unlimited storage” isn’t really accurate. It’s witness data in a taproot transaction, so the block size limit still applies. Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number.
- rijndael
On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> I'm curious what opinions exist and what actions might be taken by core developers regarding storing unlimited amounts of NFT (or other?) content as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal scheme is elegant and genius IMHO, but when I think about the future disk use of all unpruned nodes, I question whether unlimited storage is wise to allow for such use cases. Wouldn't it be better to find a way to impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal construct for proof of ownership in the real world, so that real property can be transferred on the blockchain using ordinals, but storing the property itself on the blockchain seems nonsensical to me.
[-- Attachment #2: Type: text/html, Size: 1818 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
2023-01-27 12:58 ` rot13maxi
@ 2023-01-27 13:21 ` Andrew Poelstra
2023-01-27 15:43 ` Aymeric Vitte
` (2 more replies)
2023-02-03 19:56 ` Melvin Carvalho
2023-02-06 17:31 ` Claus Ehrenberg
3 siblings, 3 replies; 22+ messages in thread
From: Andrew Poelstra @ 2023-01-27 13:21 UTC (permalink / raw)
To: Robert Dickinson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]
On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal
> scheme is elegant and genius IMHO, but when I think about the future disk
> use of all unpruned nodes, I question whether unlimited storage is wise to
> allow for such use cases. Wouldn't it be better to find a way to impose a
> size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal construct
> for proof of ownership in the real world, so that real property can be
> transferred on the blockchain using ordinals, but storing the property
> itself on the blockchain seems nonsensical to me.
Unfortunately, as near as I can tell there is no sensible way to prevent
people from storing arbitrary data in witnesses without incentivizing
even worse behavior and/or breaking legitimate use cases.
If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).
But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable.
There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold. But
from a technical point of view, I don't see any principled way to stop
this.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
2 siblings, 1 reply; 22+ messages in thread
From: Aymeric Vitte @ 2023-01-27 15:43 UTC (permalink / raw)
To: Andrew Poelstra, Bitcoin Protocol Discussion, Robert Dickinson
Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit :
> if people were storing NFTs and other crap on the
> chain, then the Bitcoin fee market would become entangled with random
> pump&dump markets
So you mean that Bitcoin is out for NFTs, Metaverse and "web3"?
LN is good but I don't think it can really adapt to everything, what I
proposed yesterday looks complementary
I clearly dislike the current NFTs existing systems, and to make it
short NFTs as a whole until recently, it depends on what people mean by
"NFT", and I did dislike any solution based on OP_RETURN (shxtty stuff
flooding bitcoin with stupid proofs of nothing)
BUT I changed my mind, one can say that I am contradicting myself
everywhere (links in the proposals), but no, explaining why in the proposals
Note that in my proposals you don't need to "mint" the NFTs (using a
third party but not a stupid ethereum/bitcoin like super sidechain) and
that you can reference millions of them in one transaction (low value
NFTs like loyalty programms, discount coupons) in that case of course
the low value NFTs are centralized
That's the future, Bitcoin being out of this does not look plausible,
currently NOBODY envisions bitcoin or LN for a web3 system, so people
here might destroy my proposals, then please do, but I find them quite
good compared to whatever exist
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 13:21 ` Andrew Poelstra
2023-01-27 15:43 ` Aymeric Vitte
@ 2023-01-28 4:26 ` Robert Dickinson
2023-12-29 12:27 ` Greg Tonoski
2 siblings, 0 replies; 22+ messages in thread
From: Robert Dickinson @ 2023-01-28 4:26 UTC (permalink / raw)
Cc: Bitcoin Protocol Discussion
On Fri, Jan 27, 2023 at 10:21 AM Andrew Poelstra
<apoelstra@wpsoftware•net> wrote:
8<
> Unfortunately, as near as I can tell there is no sensible way to prevent
> people from storing arbitrary data in witnesses without incentivizing
> even worse behavior and/or breaking legitimate use cases.
8<
> There's a reasonable argument that this sort of data is toxic to the
> network, since even though "the market is willing to bear" the price of
> scares blockspace, if people were storing NFTs and other crap on the
> chain, then the Bitcoin fee market would become entangled with random
> pump&dump markets, undermining legitimate use cases and potentially
> preventing new technology like LN from gaining a strong foothold. But
> from a technical point of view, I don't see any principled way to stop
> this.
>
>
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
Thank you for your reply and explanations. If it be so, then I think
the principled route would be to make it a priority to continuously
educate people on the morals of the matter. Rather than for fads and
scams, the world would be a better place if ordinal inscriptions were
used for enduring, practical, and universally beneficial purposes,
such as for domain name inscription to solve the DNS centralization
problem.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 12:58 ` rot13maxi
@ 2023-01-28 10:58 ` alicexbt
2023-01-29 10:34 ` Robert Dickinson
0 siblings, 1 reply; 22+ messages in thread
From: alicexbt @ 2023-01-28 10:58 UTC (permalink / raw)
To: Bitcoin Protocol Discussion; +Cc: Robert Dickinson
Hi Bitcoin Developers,
> Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number.
I completely agree with this.
> If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys.
> There's a reasonable argument that this sort of data is toxic to the
network, since even though "the market is willing to bear" the price of
scares blockspace, if people were storing NFTs and other crap on the
chain, then the Bitcoin fee market would become entangled with random
pump&dump markets, undermining legitimate use cases and potentially
preventing new technology like LN from gaining a strong foothold.
Initially I considered ordinals and the use of witness for inscriptions useless and harmful. However I have changed my opinion after looking at different things and reading several comments. I do not consider such things 'useless' or 'crap' and it won't affect bitcoin fee market negatively. There is no threat to LN as well.
I consider every bitcoin transaction a legit use case and would like to share an example and different perspective of how such inscriptions might be used at different places:
During the festival of Diwali, it is a common tradition among many Indian families to buy gold coins with the image of the goddess Laxmi, the goddess of wealth and prosperity. The coins are often bought as a symbol of good luck and prosperity for the upcoming year. They may also be given as gifts to family and friends or used as a form of investment. The coins can be purchased from a variety of sources, including jewelry stores and online retailers.
If people start buying bitcoin during Diwali, and sellers use the witness to include the image of Laxmi in the inputs used, it would be an innovative way of combining traditional customs with modern technology. Since some users consider bitcoin as digital gold, I won't be surprised if this really happens in future and won't consider it bad as the transactions are paying for block space used.
/dev/fd0
floppy disc guy
Sent with Proton Mail secure email.
------- Original Message -------
On Friday, January 27th, 2023 at 6:28 PM, rot13maxi via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hello,
>
> “Unlimited storage” isn’t really accurate. It’s witness data in a taproot transaction, so the block size limit still applies. Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number.
>
> - rijndael
>
> On Fri, Jan 27, 2023 at 7:44 AM, Robert Dickinson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > I'm curious what opinions exist and what actions might be taken by core developers regarding storing unlimited amounts of NFT (or other?) content as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal scheme is elegant and genius IMHO, but when I think about the future disk use of all unpruned nodes, I question whether unlimited storage is wise to allow for such use cases. Wouldn't it be better to find a way to impose a size limit similar to OP_RETURN for such inscriptions?
> >
> > I think it would be useful to link a sat to a deed or other legal construct for proof of ownership in the real world, so that real property can be transferred on the blockchain using ordinals, but storing the property itself on the blockchain seems nonsensical to me.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 15:43 ` Aymeric Vitte
@ 2023-01-28 16:47 ` Aymeric Vitte
0 siblings, 0 replies; 22+ messages in thread
From: Aymeric Vitte @ 2023-01-28 16:47 UTC (permalink / raw)
To: Andrew Poelstra, Bitcoin Protocol Discussion, Robert Dickinson
I saw the other posts, then storage in witness, no, ordinals no for now,
let's keep things simple and understandable
I forgot to mention that the proposals envision a "local bitcoin" (for a
metaverse for example) wich is a fork of Bitcoin code, but of course not
a fork of Bitcoin, and which of course does not store anything in the
main Bitcoin chain, but which remains compatible (tx format) and coins
between chains can be swapped
Maybe nobody care, but the idea is to put bitcoin into the party as an
alternative to this ethereum mess
Le 27/01/2023 à 16:43, Aymeric Vitte a écrit :
>
> Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit :
>> if people were storing NFTs and other crap on the
>> chain, then the Bitcoin fee market would become entangled with random
>> pump&dump markets
> So you mean that Bitcoin is out for NFTs, Metaverse and "web3"?
>
> LN is good but I don't think it can really adapt to everything, what I
> proposed yesterday looks complementary
>
> I clearly dislike the current NFTs existing systems, and to make it
> short NFTs as a whole until recently, it depends on what people mean by
> "NFT", and I did dislike any solution based on OP_RETURN (shxtty stuff
> flooding bitcoin with stupid proofs of nothing)
>
> BUT I changed my mind, one can say that I am contradicting myself
> everywhere (links in the proposals), but no, explaining why in the proposals
>
> Note that in my proposals you don't need to "mint" the NFTs (using a
> third party but not a stupid ethereum/bitcoin like super sidechain) and
> that you can reference millions of them in one transaction (low value
> NFTs like loyalty programms, discount coupons) in that case of course
> the low value NFTs are centralized
>
> That's the future, Bitcoin being out of this does not look plausible,
> currently NOBODY envisions bitcoin or LN for a web3 system, so people
> here might destroy my proposals, then please do, but I find them quite
> good compared to whatever exist
>
>
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-28 10:58 ` alicexbt
@ 2023-01-29 10:34 ` Robert Dickinson
2023-01-31 8:58 ` Erik Aronesty
0 siblings, 1 reply; 22+ messages in thread
From: Robert Dickinson @ 2023-01-29 10:34 UTC (permalink / raw)
Cc: Bitcoin Protocol Discussion
On Sat, Jan 28, 2023 at 7:58 AM alicexbt <alicexbt@protonmail•com> wrote:
>
> Hi Bitcoin Developers,
>
> > Anyone who runs an unpruned bitcoin node should be capacity-planning their disk space assuming that in the future blocks will be more full - as demand for blockspace increases, people will make better use of the space that we already have and average block weight will trend upwards. If you’re thinking about how much disk you will need when we have consistently full blocks, ordinal inscriptions don’t change that number.
>
> I completely agree with this.
I fully agree with this too. It was a sloppy remark on my part--
thanks for claifying. Underlying my remark was a bit of disgust from
knowing that in the future, a (perhaps large) X number of GB of what
should have been financial data will actually turn out to be something
else entirely. Time/space on the Bitcoin blockchain is a shared
limited resource and should be treated accordingly. We can say "no
worries...the price and demand will sort everything out," but
hopefully we all want Bitcoin to be the best financial tool it can be.
“If the ax is not sharp and he does not make it sharp, then he must
use more strength. Wisdom helps one to do well.”
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-29 10:34 ` Robert Dickinson
@ 2023-01-31 8:58 ` Erik Aronesty
0 siblings, 0 replies; 22+ messages in thread
From: Erik Aronesty @ 2023-01-31 8:58 UTC (permalink / raw)
To: Robert Dickinson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
my only concern is that as block space gets limited the likelihood of soft
fork opcode tech improvement proposals getting accepted by the community
goes down
schnorr sigs are extremely useful to me (anon, cheap multisig)
and some sort of vault tech would be very helpful as well
[-- Attachment #2: Type: text/html, Size: 496 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
2023-01-27 12:58 ` rot13maxi
2023-01-27 13:21 ` Andrew Poelstra
@ 2023-02-03 19:56 ` Melvin Carvalho
2023-02-04 14:25 ` Kostas Karasavvas
2023-02-06 17:31 ` Claus Ehrenberg
3 siblings, 1 reply; 22+ messages in thread
From: Melvin Carvalho @ 2023-02-03 19:56 UTC (permalink / raw)
To: Robert Dickinson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> napsal:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
>
Low tech solution: miners charge a premium for storing images in the block
chain. Say 2x, 5x, 10x.
This encourages bitcoin to be used as a financial network, while increasing
the security budget.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2119 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-02-03 19:56 ` Melvin Carvalho
@ 2023-02-04 14:25 ` Kostas Karasavvas
2023-02-06 16:39 ` Erik Aronesty
0 siblings, 1 reply; 22+ messages in thread
From: Kostas Karasavvas @ 2023-02-04 14:25 UTC (permalink / raw)
To: Melvin Carvalho, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> napsal:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>>
Personally, I was always considering future disk use at full capacity
anyway (and planning accordingly). Even without inscriptions/ordinals that
would happen. The latter competes for block space and are paying tx fees so
I don't see it as that much harmful (esp.now that it is out there... I
would be more conservative if we were talking about introducing it!).
> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>>
>
> Low tech solution: miners charge a premium for storing images in the block
> chain. Say 2x, 5x, 10x.
>
> This encourages bitcoin to be used as a financial network, while
> increasing the security budget.
>
How would you enforce this technically? I only see it feasible if miners
agree by social contract.
[-- Attachment #2: Type: text/html, Size: 3043 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-02-04 14:25 ` Kostas Karasavvas
@ 2023-02-06 16:39 ` Erik Aronesty
0 siblings, 0 replies; 22+ messages in thread
From: Erik Aronesty @ 2023-02-06 16:39 UTC (permalink / raw)
To: Kostas Karasavvas, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
its trivial to store images in such a way that they look like legit
transactions.
this was done, in the past, using large numbers of multisig output
addresses that encode the images.
given the goals of the project, introducing this sort of censorship into
bitcoin seems fundamentally undesirable
[-- Attachment #2: Type: text/html, Size: 384 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
` (2 preceding siblings ...)
2023-02-03 19:56 ` Melvin Carvalho
@ 2023-02-06 17:31 ` Claus Ehrenberg
2023-02-06 18:05 ` Erik Aronesty
3 siblings, 1 reply; 22+ messages in thread
From: Claus Ehrenberg @ 2023-02-06 17:31 UTC (permalink / raw)
To: Robert Dickinson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
The inscriptions are designed to be easy to use, they even specify that
mime types should be used. I'd say, the way the data is stored is anything
but 'obscure'. UIs will be popping up to make this really easy. The main
chain can't be censored, what's in a block is in a block. I'm predicting a
huge success.
So, are we ready to accept that we'll likely see the first pictures with
insults or worse in the Bitcoin chain? I really like the idea, but the risk
is pretty obvious. I think it would be prudent to have at least an opt-out
feature for the data. So that it's possible to use the chain without the
potentially malicious content. That means the content shouldn't live in the
essential data of the main chain. Better would be something like the
extension blocks in Litecoin.
Best Regards
Claus
On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2571 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-02-06 17:31 ` Claus Ehrenberg
@ 2023-02-06 18:05 ` Erik Aronesty
2023-02-07 12:17 ` Aymeric Vitte
0 siblings, 1 reply; 22+ messages in thread
From: Erik Aronesty @ 2023-02-06 18:05 UTC (permalink / raw)
To: Claus Ehrenberg, Bitcoin Protocol Discussion; +Cc: Robert Dickinson
[-- Attachment #1: Type: text/plain, Size: 2699 bytes --]
there are already images encoded in the chain using multisig. when we
eliminated the max-witness size in 2017, that made it a bit cheaper, that's
all (one tx instead of many)
https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
my favorite one is the javascript exploit for people that like to render
untrusted blockchain data in their browser
the script to interpret these is trivial, and it's not much harder to add a
mime type
On Mon, Feb 6, 2023 at 12:34 PM Claus Ehrenberg via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> The inscriptions are designed to be easy to use, they even specify that
> mime types should be used. I'd say, the way the data is stored is anything
> but 'obscure'. UIs will be popping up to make this really easy. The main
> chain can't be censored, what's in a block is in a block. I'm predicting a
> huge success.
>
> So, are we ready to accept that we'll likely see the first pictures with
> insults or worse in the Bitcoin chain? I really like the idea, but the risk
> is pretty obvious. I think it would be prudent to have at least an opt-out
> feature for the data. So that it's possible to use the chain without the
> potentially malicious content. That means the content shouldn't live in the
> essential data of the main chain. Better would be something like the
> extension blocks in Litecoin.
>
> Best Regards
> Claus
>
> On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> I'm curious what opinions exist and what actions might be taken by core
>> developers regarding storing unlimited amounts of NFT (or other?) content
>> as witness data (https://docs.ordinals.com/inscriptions.html). The
>> ordinal scheme is elegant and genius IMHO, but when I think about the
>> future disk use of all unpruned nodes, I question whether unlimited storage
>> is wise to allow for such use cases. Wouldn't it be better to find a way to
>> impose a size limit similar to OP_RETURN for such inscriptions?
>>
>> I think it would be useful to link a sat to a deed or other legal
>> construct for proof of ownership in the real world, so that real property
>> can be transferred on the blockchain using ordinals, but storing the
>> property itself on the blockchain seems nonsensical to me.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3981 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-02-06 18:05 ` Erik Aronesty
@ 2023-02-07 12:17 ` Aymeric Vitte
0 siblings, 0 replies; 22+ messages in thread
From: Aymeric Vitte @ 2023-02-07 12:17 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion, Claus Ehrenberg
Cc: Robert Dickinson
Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit :
> my favorite one is the javascript exploit for people that like to
> render untrusted blockchain data in their browser
Taking this example to show that from my standpoint it's not a good idea
to store "big things" in the blockchain, but it's a good idea to store
proofs of something ( then this is the rationale for this change request
https://github.com/bitcoin/bitcoin/issues/27043), we all know that there
are plenty of useless things already stored in the blockchain, now if
people want to pay to store big things, then let them do it
But how can you validate what is stored? Simple answer: you can't, I
take in my NFT proposal the example of js code loading, it's impossible
to be sure of the code loaded (and it is supposed to evolve, then which
version is correct in the blockchain can be mysterious) without using a
third party, that's what I am doing here: https://peersm.com/wallet, the
third party is my github repo, the code self validates that it is the
correct one and the user must check the hash, of course the code could
lie then you should better embed the check in a bookmarklet, the page
can't lie, and of course I could be a thief then others should check
the code and seed the hash somewhere, even if clearly explained that the
code must be used off line it's not difficult to invent different things
to steal the keys
Same principle applies with my NFT proposal (which can be real things,
so impossible to store in the blockchain): a third party allowing a
timestamp is used to prove that you are the seeder of the NFT (first
owner), minting can't be trusted and then becomes useless with the third
party, so you spare some bitcoin transactions
Using a third party does not mean that the blockchain is of no use,
again the blockchain will validate the life of the NFT and it remains
decentralized like lightning
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-01-27 13:21 ` Andrew Poelstra
2023-01-27 15:43 ` 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
2 siblings, 2 replies; 22+ messages in thread
From: Greg Tonoski @ 2023-12-29 12:27 UTC (permalink / raw)
To: bitcoin-dev
> Unfortunately, as near as I can tell there is no sensible way to
> prevent people from storing arbitrary data in witnesses ...
To prevent "from storing arbitrary data in witnesses" is the extreme
case of the size limit discussed in this thread. Let's consider it along
with other (less radical) options in order not to lose perspective, perhaps.
> ...without incentivizing even worse behavior and/or breaking
> legitimate use cases.
I can't find evidence that would support the hypothesis. There had not
been "even worse behavior and/or breaking legitimate use cases" observed
before witnesses inception. The measure would probably restore
incentives structure from the past.
As a matter of fact, it is the current incentive structure that poses
the problem - incentivizes worse behavior ("this sort of data is toxic
to the network") and breaks legitimate use cases like a simple transfer
of BTC.
> If we ban "useless data" then it would be easy for would-be data
> storers to instead embed their data inside "useful" data such as dummy
> signatures or public keys.
There is significant difference when storing data as dummy signatures
(or OP_RETURN) which is much more expensive than (discounted) witness.
Witness would not have been chosen as the storage of arbitrary data if
it cost as much as alternatives, e.g. OP_RETURN.
Also, banning "useless data" seems to be not the only option suggested
by the author who asked about imposing "a size limit similar to OP_RETURN".
> But from a technical point of view, I don't see any principled way to
> stop this.
Let's discuss ways that bring improvement rather than inexistence of a
perfect technical solution that would have stopped "toxic data"/"crap on
the chain". There are at least a few:
- https://github.com/bitcoin/bitcoin/pull/28408
- https://github.com/bitcoin/bitcoin/issues/29146
- deprecate OP_IF opcode.
I feel like the elephant in the room has been brought up. Do you want to
maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-12-29 12:27 ` Greg Tonoski
@ 2023-12-29 19:01 ` Nagaev Boris
2023-12-30 9:58 ` Erik Aronesty
1 sibling, 0 replies; 22+ messages in thread
From: Nagaev Boris @ 2023-12-29 19:01 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion
On Fri, Dec 29, 2023 at 1:34 PM Greg Tonoski via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> There is significant difference when storing data as dummy signatures
> (or OP_RETURN) which is much more expensive than (discounted) witness.
> Witness would not have been chosen as the storage of arbitrary data if
> it cost as much as alternatives, e.g. OP_RETURN.
Hi Greg!
How about storing data in multisig signatures? Make a 1/n multisig and
store the data in (n-1) dummy public keys. It is stored in witness and
is quite efficient and hard to filter out only if together with
legitimate multisigs.
Another smart place for hidden data is Merkle proof in Taproot. The
depth is limited to 128 levels, so put 1 valid leaf and add data to
127 fake elements to calculate the Merkle root.
I think there are more ways like this. If the current place is banned,
they can always waste money in other parts of bitcoin transactions. It
is impossible to stop someone who can afford to waste money from doing
it. (Well, it is, but not in a decentralized voluntary way of
Bitcoin.) My approach is just to wait for them to run out of money and
use Lightning Network for payments meanwhile.
--
Best regards,
Boris Nagaev
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
1 sibling, 1 reply; 22+ messages in thread
From: Erik Aronesty @ 2023-12-30 9:58 UTC (permalink / raw)
To: Greg Tonoski, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
Bitcoin already has a spam prevention system called "fees". I don't
believe it's insufficient. The only issue is the stochastic nature of its
effectiveness
Which can be resolved with things like payment pools, tree payments (
https://utxos.org/uses/scaling/), etc.
On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Unfortunately, as near as I can tell there is no sensible way to
> > prevent people from storing arbitrary data in witnesses ...
>
> To prevent "from storing arbitrary data in witnesses" is the extreme
> case of the size limit discussed in this thread. Let's consider it along
> with other (less radical) options in order not to lose perspective,
> perhaps.
>
> > ...without incentivizing even worse behavior and/or breaking
> > legitimate use cases.
>
> I can't find evidence that would support the hypothesis. There had not
> been "even worse behavior and/or breaking legitimate use cases" observed
> before witnesses inception. The measure would probably restore
> incentives structure from the past.
>
> As a matter of fact, it is the current incentive structure that poses
> the problem - incentivizes worse behavior ("this sort of data is toxic
> to the network") and breaks legitimate use cases like a simple transfer
> of BTC.
>
> > If we ban "useless data" then it would be easy for would-be data
> > storers to instead embed their data inside "useful" data such as dummy
> > signatures or public keys.
>
> There is significant difference when storing data as dummy signatures
> (or OP_RETURN) which is much more expensive than (discounted) witness.
> Witness would not have been chosen as the storage of arbitrary data if
> it cost as much as alternatives, e.g. OP_RETURN.
>
> Also, banning "useless data" seems to be not the only option suggested
> by the author who asked about imposing "a size limit similar to OP_RETURN".
>
> > But from a technical point of view, I don't see any principled way to
> > stop this.
>
> Let's discuss ways that bring improvement rather than inexistence of a
> perfect technical solution that would have stopped "toxic data"/"crap on
> the chain". There are at least a few:
> - https://github.com/bitcoin/bitcoin/pull/28408
> - https://github.com/bitcoin/bitcoin/issues/29146
> - deprecate OP_IF opcode.
>
> I feel like the elephant in the room has been brought up. Do you want to
> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3819 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2023-12-30 9:58 ` Erik Aronesty
@ 2024-01-01 13:33 ` Brad Morrison
2024-01-01 16:08 ` Erik Aronesty
0 siblings, 1 reply; 22+ messages in thread
From: Brad Morrison @ 2024-01-01 13:33 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]
Erik,
Fees AKA costs are the best spam control system and I thank you for
highlighting that.
However, I think that bitcoin has yet to receive sufficient payments
usage to challenge credit card payments system when it comes to a race
to the bottom in terms of processing transactional fees.
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.
A focus on lowering fees by increasing the block size by 10x is the
simplest method to start accepting more payments in bitcoin from larger
businesses.
Brad
On 2023-12-30 01:58, Erik Aronesty via bitcoin-dev wrote:
> Bitcoin already has a spam prevention system called "fees". I don't believe it's insufficient. The only issue is the stochastic nature of its effectiveness
>
> Which can be resolved with things like payment pools, tree payments (https://utxos.org/uses/scaling/), etc.
>
> On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>> Unfortunately, as near as I can tell there is no sensible way to
>>> prevent people from storing arbitrary data in witnesses ...
>>
>> To prevent "from storing arbitrary data in witnesses" is the extreme
>> case of the size limit discussed in this thread. Let's consider it along
>> with other (less radical) options in order not to lose perspective, perhaps.
>>
>>> ...without incentivizing even worse behavior and/or breaking
>>> legitimate use cases.
>>
>> I can't find evidence that would support the hypothesis. There had not
>> been "even worse behavior and/or breaking legitimate use cases" observed
>> before witnesses inception. The measure would probably restore
>> incentives structure from the past.
>>
>> As a matter of fact, it is the current incentive structure that poses
>> the problem - incentivizes worse behavior ("this sort of data is toxic
>> to the network") and breaks legitimate use cases like a simple transfer
>> of BTC.
>>
>>> If we ban "useless data" then it would be easy for would-be data
>>> storers to instead embed their data inside "useful" data such as dummy
>>> signatures or public keys.
>>
>> There is significant difference when storing data as dummy signatures
>> (or OP_RETURN) which is much more expensive than (discounted) witness.
>> Witness would not have been chosen as the storage of arbitrary data if
>> it cost as much as alternatives, e.g. OP_RETURN.
>>
>> Also, banning "useless data" seems to be not the only option suggested
>> by the author who asked about imposing "a size limit similar to OP_RETURN".
>>
>>> But from a technical point of view, I don't see any principled way to
>>> stop this.
>>
>> Let's discuss ways that bring improvement rather than inexistence of a
>> perfect technical solution that would have stopped "toxic data"/"crap on
>> the chain". There are at least a few:
>> - https://github.com/bitcoin/bitcoin/pull/28408
>> - https://github.com/bitcoin/bitcoin/issues/29146
>> - deprecate OP_IF opcode.
>>
>> I feel like the elephant in the room has been brought up. Do you want to
>> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5398 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2024-01-01 13:33 ` Brad Morrison
@ 2024-01-01 16:08 ` Erik Aronesty
2024-01-03 9:11 ` Brad Morrison
0 siblings, 1 reply; 22+ messages in thread
From: Erik Aronesty @ 2024-01-01 16:08 UTC (permalink / raw)
To: Brad Morrison; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
>
> .
>
> 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: 1675 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2024-01-01 16:08 ` Erik Aronesty
@ 2024-01-03 9:11 ` Brad Morrison
2024-01-03 13:05 ` Erik Aronesty
0 siblings, 1 reply; 22+ messages in thread
From: Brad Morrison @ 2024-01-03 9:11 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Ordinal Inscription Size Limits
2024-01-03 9:11 ` Brad Morrison
@ 2024-01-03 13:05 ` Erik Aronesty
0 siblings, 0 replies; 22+ messages in thread
From: Erik Aronesty @ 2024-01-03 13:05 UTC (permalink / raw)
To: Brad Morrison; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2024-01-03 13:05 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox