Re: [bitcoin-dev] Ordinals BIP PR
Hello, I have developed nodes/wallets for Bitcoin and Bitcoin-derived Altcoins. 3rd-party Bitcoin developers take BIPs very seriously, basically as must-implement/must-comply features. Therefore, I think it would be best to restrict BIPs to the minimum necessary to implement a complying node/wallet. Cheers! Claus On Thu, Nov 9, 2023 at 1:43 PM Casey Rodarmor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > Luke is definitely entitled to his opinions about ordinals, and I > certainly understand why people may not like ordinals and inscriptions. > > I don't think that ordinals are "nonsense", an "attack on Bitcoin", or > that I'm dishonest, as Luke implies, or that my actions are an attempt to > "harm/destroy Bitcoin". > > I think that whether or not ordinals are good is something about which > reasonable people do and will disagree, and that an impartial BIP editor > would recognize this above their own personal feelings about the matter. > > Also, regarding: > > > There is a debate on the PR whether the "technically unsound, ..., or > not in keeping with the Bitcoin philosophy." or "must represent a net > improvement." clauses (BIP 2) are relevant. > > As I said in my initial email, I think these standards are being applied > in a way that they have not been to previous BIPs, which include all manner > of things, including changes to bitcoin which are nearly unanimously > thought to be quite harmful if adopted. > > Best, > Casey > > On Mon, Oct 23, 2023 at 11:35 AM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Everything standardized between Bitcoin software is eligible to be and >> should be a BIP. I completely disagree with the claim that it's used for >> too many things. >> >> SLIPs exist for altcoin stuff. They shouldn't be used for things related >> to Bitcoin. >> >> BOLTs also shouldn't have ever been a separate process and should really >> just get merged into BIPs. But at this point, that will probably take >> quite a bit of effort, and obviously cooperation and active involvement >> from the Lightning development community. >> >> Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time >> to keep up. There are several PRs far more important than Ordinals >> nonsense that need to be triaged and probably merged. >> >> The issue with Ordinals is that it is actually unclear if it's eligible >> to be a BIP at all, since it is an attack on Bitcoin rather than a >> proposed improvement. There is a debate on the PR whether the >> "technically unsound, ..., or not in keeping with the Bitcoin >> philosophy." or "must represent a net improvement." clauses (BIP 2) are >> relevant. Those issues need to be resolved somehow before it could be >> merged. I have already commented to this effect and given my own >> opinions on the PR, and simply pretending the issues don't exist won't >> make them go away. (Nor is it worth the time of honest people to help >> Casey resolve this just so he can further try to harm/destroy Bitcoin.) >> >> Luke >> >> >> On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote: >> > On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev >> wrote: >> >> I have _not_ requested a BIP for OpenTimestamps, even though it is of >> much >> >> wider relevance to Bitcoin users than Ordinals by virtue of the fact >> that much >> >> of the commonly used software, including Bitcoin Core, is timestamped >> with OTS. >> >> I have not, because there is no need to document every single little >> protocol >> >> that happens to use Bitcoin with a BIP. >> >> >> >> Frankly we've been using BIPs for too many things. There is no >> avoiding the act >> >> that BIP assignment and acceptance is a mark of approval for a >> protocol. Thus >> >> we should limit BIP assignment to the minimum possible: _extremely_ >> widespread >> >> standards used by the _entire_ Bitcoin community, for the core mission >> of >> >> Bitcoin. >> >> >> > This would eliminate most wallet-related protocols e.g. BIP69 (sorted >> > keys), ypubs, zpubs, etc. I don't particularly like any of those but if >> > they can't be BIPs then they'd need to find another spec repository >> > where they wouldn't be lost and where updates could be tracked. >> > >> > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not >> a BIP >> > in part because of perceived friction and exclusivity of the BIPs repo. >> > But I'm not thrilled with this situation. >> > >> > In fact, I would prefer that OpenTimestamps were a BIP :). >> > >> >> It's notable that Lightning is _not_ standardized via the BIP process. >> I think >> >> that's a good thing. While it's arguably of wide enough use to warrent >> BIPs, >> >> Lightning doesn't need the approval of Core maintainers, and using >> their >> >> separate BOLT process makes that clear. >> >> >> > Well, LN is a bit special because it's so big that it can have its own >> > spec repo which is actively maintaine
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
I propose to require all data to be in the op_return output PLUS add a required op_return_hash field, which is checked by consensus. So that node can re-validate the chain without having to store/download/look at the contents of op_return data. The benefit of that little redundancy is that "content-sensitive" communities can ignore the date they don't like. Cheers Claus On Thu, Feb 16, 2023 at 7:30 PM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It's super unclear how long it could take for such a change to be adopted > > Then the answer is simple, see: > https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7#workaround-to-the-80b-op_return-limitation > > Outstandingly, very, mega, bad, but working, bringing bitcoin back 10 > years ago > > But why not? If bitcoin folks don't get that we need a 1tx storage > solution for the future, then let's bring back bitcoin into the past and > destroy coins > Le 12/02/2023 à 17:23, Aymeric Vitte a écrit : > > https://github.com/bitcoin/bitcoin/issues/27043#issuecomment-1427069403 > > "What is the process to have someone do the PR for this? Or I do it and > most likely it will be a very shxtty one since I am not a C/C++ expert, > then wasting the time of everybody > > It's urgently required, I did consider OP_RETURN as a dart in the past but > changed my mind, it's adapted to the current evolutions, not flooding > bitcoin with 2 txs while only 1 is needed > > If not the best 1 tx solution is super simple: store in addresses, and > super bad at the end because burning bitcoins, while still not expensive if > you don't need to store big things" > > Le 05/02/2023 à 19:12, Russell O'Connor via bitcoin-dev a écrit : > > > > On Sat., Feb. 4, 2023, 21:01 Peter Todd, wrote: > >> >> >> On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via >> bitcoin-dev wrote: >> >Since bytes in the witness are cheaper than bytes in the script pubkey, >> >there is a crossover point in data size where it will simply be cheaper >> to >> >use witness data. Where that crossover point is depends on the finer >> >details of the overhead of the two methods, but you could make some >> >reasonable assumptions. Such a calculation could form the basis of a >> >reasonable OP_RETURN proposal. I don't know if it would be persuasive, >> but >> >it would at least be coherent. >> >> I don't think it's worth the technical complexity trying to carefully >> argue a specific limit. Let users decide for themselves how they want to >> use OpReturn. >> > > Even better. > >> > > ___ > bitcoin-dev mailing > listbitcoin-dev@lists.linuxfoundation.orghttps://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 > > > -- > 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 > ___ 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] Proposal: Low Energy Bitcoin PoW
> Ultimately all currency security derives from energy consumption. > Everything eventually resolves down to proof-of-work. This is ideology. Yes, without energy and work, not many things happen. But the amounts of energy and work to achieve a goal vary widely. Detailed analysis comparing one alternative with the other in depth is required. And I would not look for order-of-magnitude improvements, 25% better is also a big deal, if discovered. > * Proof-of-space simply moves the work to the construction of more storage devices. One needs a cost/benefit analysis, not just an account of the cost. For example, if PoW could do calculations that are otherwise useful (maybe solve a queue of standardized math-jobs, such as climate simulations) there would be more benefit, or, let's say the data storage in proof-of-space is useful. > * Proof-of-stake simply moves the work to stake-grinding attacks. Simply not true, there are PoS implementations that are immune to stake-grinding attacks, and even where not, the possible amount of computations is limited compared to PoW > * The optical proof-of-work simply moves the work to the construction of more miners. The idea was to shift from energy to cap-ex. We can get a financial penalty for misbehavior from three sources: - cost of energy/labor (PoW) - cost of capital (PoS) - cost of cap-ex There might be a better mix than PoW only. I have written code for mixed PoW/PoS systems and it works. Adding more cap-ex to the mix can make sense, but the environmental impact needs to be analyzed, it could also make it worse than just the use of electricity. At least electricity as such does not leave waste behind. Mining in orbit with solar power would be totally acceptable. > At least, proof-of-work is honest about its consumption of resources. Agreed, but we can't be satisfied with that. If we try hard enough we can do better. Cheers Claus On Tue, May 18, 2021 at 8:47 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > A few things jump out at me as I read this proposal > > > > First, deriving the hardness from capex as opposed to opex switches the > privilege from those who have cheap electricity to those who have access to > chip manufacturers/foundries. While this is similarly the case for Bitcoin > ASICS today, the longevity of the PoW algorithm has led to a better > distribution of knowledge and capital goods required to create ASICS. The > creation of a new PoW of any kind, hurts this dimension of decentralization > as we would have to start over from scratch on the best way to build, > distribute, and operate these new pieces of hardware at scale. While I have > not combed over the PoW proposed here in fine detail, the more complicated > the algorithm is, the more it privileges those with specific knowledge > about it and the manufacturing process. > > > > The competitive nature of Bitcoin mining is such that miners will be > willing to spend up to their expected mining reward in their operating > costs to continue to mine. Let's suppose that this new PoW was adopted, > miners will continue to buy these chips in ever increasing quantities, > turning the aforementioned CAPEX into a de facto OPEX. This has a few > consequences. First it just pushes the energy consumption upstream to the > chip manufacturing process, rather than eliminating it. And it may trade > some marginal amount of the energy consumption for the set of resources it > takes to educate and create chip manufacturers. The only way to avoid that > cost being funneled back into more energy consumption is to make the > barrier to understanding of the manufacturing process sufficiently > difficult so as to limit the proliferation of these chips. Again, this > privileges the chip manufacturers as well as those with close access to the > chip manufacturers. > > > > As far as I can tell, the only thing this proposal actually does is > create a very lucrative business model for those who sell this variety of > chips. Any other effects of it are transient, and in all likelihood the > transient effects create serious centralization pressure. > > > > At the end of the day, the energy consumption is foundational to the > system. The only way to do away with authorities, is to require > competition. This competition will employ ever more resources until it is > unprofitable to do so. At the base of all resources of society is energy. > You get high energy expenditure, or a privileged class of bitcoin > administrators: pick one. I suspect you'll find the vast majority of > Bitcoin users to be in the camp of the energy expenditure, since if we pick > the latter, we might as well just pack it in and give up on the Bitcoin > experiment. > > > Keagan is quite correct. > Ultimately all currency security derives from energy consumption. > Everything eventually resolves down to proof-of-work. > > * Proof-of-space simply moves the work to the construction of more storage > devices. > * Proof-o
Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
As a user, I think it's very important for me to know if Taproot is eventually coming or not. So why not make it so that if _either_ miners _or_ users decide for Taproot, it will activate no matter what. Accepting a chain split is imo the fairest way to 'resolve the conflict' (it can't be resolved anyway). That would probably mean running ST and and UASF concurrently. The upside would be that we've got a safe date for Taproot, except neither users nor miners want it. Cheers, Claus On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Ryan Grant writes: > > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > > wrote: > >> The core question always was: what do we do if miners fail to activate? > >> > >> [...] Speedy Trial takes the approach that "let's pretend we didn't > >> *actually* ask [miners]". > > > > What ST is saying is that a strategy of avoiding unnecessary risk is > > stronger than a strategy of brinkmanship when brinkmanship wasn't > > our only option. Having deescalation in the strategy toolkit makes > > Bitcoin stronger. > > I don't believe that having a plan is brinkmanship or an escalation. > > During the segwit debate, Pieter Wuille said that users should decide. > I've been thinking about that a lot, especially about what that means in > a practical sense where the normal developer / miner dynamic has failed. > > >> It's totally a political approach, to avoid facing the awkward question. > >> Since I believe that such prevaricating makes a future crisis less > >> predictable, I am forced to conclude that it makes bitcoin less robust. > > > > LOT=true does face the awkward question, but there are downsides: > > > > - in the requirement to drop blocks from apathetic miners (although > > as Luke-Jr pointed out in a previous reply on this list they have > > no contract under which to raise a complaint); and > > Surely, yes. If the users of bitcoin decide blocks are invalid, they're > invalid. With a year's warning, and developer and user consensus > against them, I think we've reached the limits of acceptable miner > apathy. > > > - in the risk of a chain split, should gauging economic majority > > support - which there is zero intrinsic tooling for - go poorly. > > Agreed that we should definitely do better here: in practice people > would rely on third party explorers for information on the other side of > the split. Tracking the cumulative work on invalid chains would be a > good idea for bitcoind in general (AJ suggested this, IIRC). > > >> Personally, I think the compromise position is using LOT=false and > >> having those such as Luke and myself continue working on a LOT=true > >> branch for future consideration. It's less than optimal, but I > >> appreciate that people want Taproot activated more than they want > >> the groundwork future upgrades. > > > > Another way of viewing the current situation is that should > > brinkmanship be necessary, then better tooling to resolve a situation > > that requires brinkmanship will be invaluable. But: > > > > - we do not need to normalize brinkmanship; > > > > - designing brinkmanship tooling well before the next crisis does > > not require selecting conveniently completed host features to > > strap the tooling onto for testing; and > > Again, openly creating a contingency plan is not brinkmanship, it's > normal. I know that considering these scenarios is uncomfortable; I > avoid conflict myself! But I feel obliged to face this as a real > possibility. > > I think we should be normalizing the understanding that bitcoin users > are the ultimate decider. By offering *all* of them the tools to do so > we show this isn't lip-service, but something that businesses and > everyone else in the ecosystem should consider. > > > - it's already the case that a UASF branch can be prepared along > > with ST (ie. without requiring LOT=false), although the code is a > > bit more complex and the appropriate stopheight a few blocks later. > > I don't believe this is true, unless you UASF before ST expires? ST is > explicitly designed *not* to give time to conclude that miners are > stalling (unless something has changed from the initial 3 month > proposal?). > > > Although your NACK is well explained, for the reasons above I am > > prepared to run code that overrides it. > > Good. In the end, we're all at the whim of the economic majority. > > Cheers! > Rusty. > ___ > 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
