Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 > > > > > >> >> ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 > >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
> 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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
> > . > > 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
Re: [bitcoin-dev] Ordinal Inscription Size Limits
On Fri, Dec 29, 2023 at 1:34 PM Greg Tonoski via bitcoin-dev 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
On Sat, Jan 28, 2023 at 7:58 AM alicexbt 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.” ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 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 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 > 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
Re: [bitcoin-dev] Ordinal Inscription Size Limits
On Fri, Jan 27, 2023 at 10:21 AM Andrew Poelstra 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 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
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 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
