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] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
Hello again dev, Due to the interest in the proposal and the prodding of certain folks, I've written up a short draft BIP of the Ephemeral Anchors idea here: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been refreshed on top of the latest V3 proposal, but the BIP itself is unaffected. Cheers, Greg On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders wrote: > Small update. > > A bit ago I went ahead and implemented ephemeral anchors on top of the V3 > proposal to see what the complexity looks like: > https://github.com/bitcoin/bitcoin/pull/26403 > > Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp > the value that is used elsewhere. > > Please let me know if you have any early feedback on this! > > Greg > > On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders wrote: > >> So it doesn't look like I'm ignoring a good question: >> >> No solid noninteractive ideas, unless we get some very flexible sighash >> softfork. Interactively, I think you can get collaborative fee bumps under >> the current consensus regime and ephemeral anchors. The child will just be >> built with inputs from different people. >> >> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne >> wrote: >> >>> I'm also very happy to see this proposal, since it gets us closer to >>> having a mechanism that allows the contribution to feerate in an >>> "unauthenticated" way, which seems to be a very helpful feature for vaults >>> and other contracting protocols. >>> >>> One possible advantage of the sponsors interface -- and I'm curious for >>> your input here Greg -- is that with sponsors, assuming we relaxed the "one >>> sponsor per sponsoree" constraint, multiple uncoordinated parties can >>> collaboratively bump a tx's feerate. A simple example would be a batch >>> withdrawal from an exchange could be created with a low feerate, and then >>> multiple users with a vested interest of expedited confirmation could all >>> "chip in" to raise the feerate with multiple sponsor transactions. >>> >>> Having a single ephemeral output seems to create a situation where a >>> single UTXO has to shoulder the burden of CPFPing a package. Is there some >>> way we could (possibly later) amend the ephemeral anchor interface to allow >>> for this kind of collaborative sponsoring? Could you maybe see "chained" >>> ephemeral anchors that would allow this? >>> >>> >>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> Excellent proposal and I agree it does capture much of the spirit of sponsors w.r.t. how they might be used for V3 protocols. The only drawbacks I see is they don't work for lower tx version contracts, so there's still something to be desired there, and that the requirement to sweep the output must be incentive compatible for the miner, or else they won't enforce it (pass the buck onto the future bitcoiners). The Ephemeral UTXO concept can be a consensus rule (see https://rubin.io/public/pdfs/multi-txn-contracts.pdf "Intermediate UTXO") we add later on in lieu of managing them by incentive, so maybe it's a cleanup one can punt. One question I have is if V3 is designed for lightning, and this is designed for lightning, is there any sense in requiring these outputs for v3? That might help with e.g. anonymity set, as well as potentially keep the v3 surface smaller. On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > does that effectively mark output B as unspendable once the child > gets confirmed? > > Not at all. It's a normal spend like before, since the parent has been > confirmed. It's completely unrestricted, not being bound to any > V3/ephemeral anchor restrictions on size, version, etc. > > On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi Greg, >> >> Thank you very much for sharing your proposal! >> >> I think there's one thing about the second part of your proposal that >> I'm missing. Specifically, assuming the scenario of a v3 transaction with >> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child >> transaction spends A and OP_TRUE, does that effectively mark output B as >> unspendable once the child gets confirmed? If so, isn't the implication >> therefore that to safely spend a transaction with an ephemeral anchor, >> all >> outputs must be spent? Thanks! >> >> Best, >> Arik >> >> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote: >> >> Hello Everyone, >> >> Following up on the "V3 Transaction" discussion here >>
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
[bitcoin-dev] Ordinal Inscription Size Limits
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
