Re: [bitcoin-dev] Ephemeral Anchors: Fixing V3 Package RBF againstpackage limit pinning
I'm not particularly persuaded, but also not wedded to either idea. Fixed up tests for the OP_TRUE case here: https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true On Fri, Feb 3, 2023 at 5:10 PM Peter Todd wrote: > On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote: > > > OP_TRUE is the obvious way to do this, and it results with a 1 on the > > stack, > > which plays better with other standardness rules. > > > > What other standardness rules? MINAMALIF? How does that interact with the > > proposal? > > It makes sense to require scripts to leave just a single OP_TRUE on the > stack > at the end of execution, as otherwise that can be a source of malleability > in > certain circumstances where the scriptSig ends up providing the OP_TRUE. I > don't believe we actually implement this as a rule right now. But you could > easily imagine that happening in a future upgrade. > > Leaving an OP_2 on the stack doesn't achieve that and would require a > special-cased workaround. Spending the time now to do the obvious thing - > use > OP_TRUE as the canonical anyone-can-spend output - avoids this issue. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ 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
On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote: > > OP_TRUE is the obvious way to do this, and it results with a 1 on the > stack, > which plays better with other standardness rules. > > What other standardness rules? MINAMALIF? How does that interact with the > proposal? It makes sense to require scripts to leave just a single OP_TRUE on the stack at the end of execution, as otherwise that can be a source of malleability in certain circumstances where the scriptSig ends up providing the OP_TRUE. I don't believe we actually implement this as a rule right now. But you could easily imagine that happening in a future upgrade. Leaving an OP_2 on the stack doesn't achieve that and would require a special-cased workaround. Spending the time now to do the obvious thing - use OP_TRUE as the canonical anyone-can-spend output - avoids this issue. -- https://petertodd.org 'peter'[:-1]@petertodd.org 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
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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think the right way so people don't invent deviant things is to > increase the size of OP_RETURN, I don't get this number of 80B, you can > hardly store a signature (of what?) in there and not the "what" if the > "what" is a hash for example > Updating the size of OP_RETURN to support a hash (or two), a signature, and maybe a few more bytes for metadata, would be very helpful in a number of scenarios. It is still a limit but a reasonable one. Otherwise, I think we'll have a lot more inscription-style scenarios. -- Christopher Allen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Indeed the witness envelope is more costly and less easy to use (or read/track) But let's take a standard P2PKH or P2WPKH output, what prevents me from adding in the beginning of scriptSig or witness while spending it: OP_PUSH OP_DROP ? Non standard ? This one makes one transaction only There are probably plenty of ways to store data, another one would be to use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the rest is data, but again several transactions... I think the right way so people don't invent deviant things is to increase the size of OP_RETURN, I don't get this number of 80B, you can hardly store a signature (of what?) in there and not the "what" if the "what" is a hash for example Le 02/02/2023 à 14:25, Rijndael via bitcoin-dev a écrit : > Hello Christopher, > > I think if the protocol that you were designing always had <80 bytes, > I'd prefer the OP_RETURN. I think the "witness envelope" has two major > disadvantages compared to the OP_RETURN method: > > 1. You need to first spend to he address that commits to the script that > encodes your data payload. So you have a two step process of first > spending to a "commitment" address and then a second spend to "reveal" > your payload. You can CPFP to get them both into the same block, but its > still two transactions, so more cost, etc. > > 2. Because of the two step process in (1), if for some reason you were > unable to get the "reveal" transaction into a block (for example there's > widespread censorship of transactions that match the format of the > "reveal" script), then you might have money that's stuck in the "commit" > stage of the protocol. The way out of this would be to get your money > out via the keypath or another tapleaf, but then you need to spend money > to cancel a step in your protocol. Of course there could be widespread > censorship of your OP_RETURNs too, but you don't have to spend funds on > the cancellation spends. > > I think (2) is actually a pretty weak argument because as we saw in the > full-rbf discussion, as long as there's some threshold number of nodes > in the network that relay transactions to miners, you can probably find > a path to a miner (IIRC the number was on the order of 15% of the > network?). So I think the big reason to pick OP_RETURN over the witness > embedding is that you save a transaction and possibly some > failure-recovery/cancellation logic. > > Obviously if your data is larger than 80 bytes, then you probably want > to do the witness-embedding method. If your data smaller, then a > pay-to-contract tweak probably the best thing from a space and > fingerprinting perspective. > > - rijndael > > > On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote: >> All other things being equal, which is better if you need to place a >> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a >> spent taproot transaction such as: >> >> OP_FALSE >> OP_IF >> OP_PUSH my64bytes >> OP_ENDIF >> >> I know that the anti-OP_RETURN folk would say “neither.” But if there >> was no other choice for a particular protocol, such as a timestamp or >> a commitment, which is better? Or is there a safer place to put 64 >> bytes that is more uncensorable but also does not clog UTXO space, >> only spent transaction `-txindex` space? >> >> My best guess was that the taproot method is better, but I suspect >> there might be some who disagree. I'd love to hear all sides. >> >> -- Christopher Allen >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- 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] Purely off-chain coin colouring
Good evening list, Apologies for posting! I've tried to keep discussion of ordinals and inscriptions off-list, because I consider it to be of little relevance to general Bitcoin development. Also, apologies for the HTML mail, but I don't have my email client configured correctly. And finally, also apologies if this breaks the thread, I was subscribed but not receiving mail, so I can't respond to the original message. AJ Towns writes: I think, however, that you can move inscriptions entirely off-chain. I wrote a little on this idea on twitter already [1], but after a bit more thought, I think pushing things even further off-chain would be plausible. Actually, my initial sketch for Ordinal NFTs worked in a similar fashion, with off-chain messages pointing to an ordinal, which could be tracked by following the chain of custody of that particular sat. I gave a workshop last year where I handed out paper wallets to participants with a private key that controlled some sats, which could both be assigned NFTs and used to sign messages as a form of provenance: https://www.youtube.com/watch?v=j5V33kV3iqo Ultimately, I decided against this design, and Peter provided an excellent explanation of some of the trade-offs of such a design in his mail, but to at least partially recap and explain my own thinking: NFT collectors have a strong revealed preference for on-chain content. The content of high-value NFTs is often stored partially or completely on chain, even if details of the NFT protocol involved actually prevents that content from being what you see when you view the NFT on a website or marketplace. User protection when off-chain content is involved is fraught. Users are not equipped, due to lack of technical knowledge, easily available, user-friendly tools, and education, to protect themselves when they buy a collectable whose content is stored off-chain. When a user buys an NFT with off-chain content, they now have the primary economic incentive to preserve that content, so that their NFT retains value and can be enjoyed or sold. Many existing NFT marketplaces that sell off-chain content do not explain this to users, or give users tools that the average, non-technical person can understand or use, which enables them to protect themselves. Even if they did give users these tools, there are tricky considerations involved. IPFS functions much like BitTorrent, so even if users were provided with an IPFS application that could persist their off-chain NFT content automatically, they might reveal their IP address, which would then be linked to ownership of their NFT, which would have privacy and safety considerations. Another issue is salience and scarcity, as has been mentioned. Off-chain content is unbounded, and thus less scarce. Usually, we design for efficiency, volume, and scale. For NFT designs, which are intended to be collectable, this is in some ways counterproductive. The above issues also make the specification and implementation of NFTs with off-chain content much more difficult. Ordinals is a project largely written by a single developer, me, with the assistance of two part time interns. It is very intentionally the simplest thing that could possibly work, much like Bitcoin itself. Sometimes I refer to it as "cave-man technology". If I was designing an off-chain NFT protocol, I would likely have had to raise money and recruit a large team, which I have not done, or be at risk of never launching anything at all. I would absolutely love for the ordinals protocol, that is, the numbering and transfer of individual satoshis, be used as the basis for alternative, off-chain NFT and colored coin schemes, with proper consideration given to the issues above. However, I would request that, to avoid confusion, these alternative schemes never be called inscriptions. I'm a dev, not a cop, but fine distinctions are hard to properly explain and understand. Inscriptions, that is, the NFT protocol which embeds content in transaction witnesses, has a particular set of trade-offs and guarantees. I want users to know that if they buy or value something they or others call an "inscription", they can rely on those trade-offs and guarantees. Another NFT protocol named "inscriptions" would make this very difficult. Additionally, I think the term "inscription" which has a connotation of permanence, and of an indelible association with a particular satoshi, is inappropriate for an off-chain NFT protocol. Sorry to belabor this point! Inscriptions have already proven very popular for a nascent protocol, beyond my expectations, and the terminology and naming is still new, so it's a critical phase in terms of understanding and education. If others are interested in developing ordinals further, a great first step would be to provide review and feedback on the BIP PR: https://github.com/bitcoin/bips/pull/1408 I have never written a BIP, so style and content feedback is especially welcome. Inscriptions themselves have
