Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
You may activate any time you want. e From: bitcoin-dev On Behalf Of Claus Ehrenberg via bitcoin-dev Sent: Wednesday, April 7, 2021 6:42 AM To: Rusty Russell ; Bitcoin Protocol Discussion Subject: 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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
Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote: Ryan Grant writes: On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev 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. I strongly disagree with this characterization of ST, primarily because there just isn't the kind of agreement you seem to be assuming. ST isn't a "lets not decide because we don't want to formulate a specific grand plan" its more of a "lets not decide, because there are very strong, and very divergent viewpoints on what a specific grand plan can or should look like, and something most people are ok with is better than nothing at all". Ultimately, there are a number of possible directions a grand plan could go, and there appear to be at least several prominent (and likely many non-prominent) individuals who would strongly disagree with any such plan, you and I likely among them :). 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. You say "developer and user consensus against them" here, but then go on to argue that its perfectly acceptable for only a small subset of users to be required to do something below. - 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). We already have a really, really great precedent for tracking economic majority, I'd argue we have great tooling here! During Segwit2x, we had multiple futures and chain-split-tokens available, including the BitMex futures with billions of dollars in daily volume! For the BCH split, ViaBTC issued similar chain split tokens. At the end of the day, economic value is going to determine the amount of hashrate on any chain, and there is a very, very strong incentive (trading fees!) for an exchange to list...more stuff, chainsplit tokens included. Why do we need to build in really janky ways to measure economic majority when there's already a great one that experience has shown us will prop up and provide reasonable signal, given any material demand. 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. While I strongly agree with your principle, I strongly disagree with the practice of how you propose going about it. Ultimately, no matter what we decide here, elsewhere, or what the process for consensus changes is, the decider will be economic activity and users voting with their Bitcoin. We should start by acknowledging that, and acknowledging that the markets will (and have!) let us know what they think when there is any kind of material disagreement. Then, we should optimize for ensuring that the market never needs to "correct the situation", because if we end up there (or in any of these kinds of scenarios), we've basically screwed the pooch. Sure, some 10% minority group (and usually less as time goes on) forking themselves off has turned out to basically be irrelevant, but if we end up with multiple
[bitcoin-dev] Prediction Markets and Bitcoin
Positives: You need money to participate even though your position size may not matter if really small based on liquidity and volume. Useful information if looking at overall sentiments especially traders Noise filter because its not same as trolling on social media Opportunity for some people to make money Entertainment and something new to discuss or confirm bias Negatives: You need money to participate. "Full nodes enforce consensus rules" becomes a meme. Full nodes will still enforce consensus rules but some full nodes are being influenced by people with money which can be anything not necessarily bitcoin. Information that may not be useful for everyone. The exchanges who have created such markets in past and the traders involved know how to manipulate illiquid markets at least for a short time period. And sometimes "markets can remain irrational longer than you can remain solvent". If such markets affect Bitcoin development in any way, it will be great opportunity for governments to attack Bitcoin. Example: Consider we have a soft fork or hard fork for confidential transaction on-chain in future, if someone is able to find a secure way to implement it. All the governments that love to spy will have some issues with it and won't be the first time if they participate in such markets indirectly to manipulate or start some investigation against exchanges involved or something else. Focus which should have been on improving Bitcoin will now shift to futures markets and their involvement in Bitcoin. I think prediction markets or such tokens might help in adding to the information we already have however they don't decide or replace anything. Bitcoin development should impact such markets and not the other way around. Nobody can stop markets from betting on something related to Bitcoin and it can even be done using P2P exchanges like HodlHodl: https://predictions.hodlhodl.com or create something new with oracles which can be implemented using DLC: https://github.com/discreetlogcontracts/dlcspecs Not everyone is a trader or interested to take risk in such markets even if a Bitcoin user from years, lot of transactions, contributions and some opinion on Taproot based on things that are publicly available to everyone but scattered. In past we had things that made some sense for prediction markets like 2x and Bcash but right now nobody has issues with Taproot and even the best traders won't be aware of all the technical details about Bitcoin development to predict something related to activation mechanism. If the point of using prediction markets is to filter noise or spam then maybe we can have one chatroom that requires some sats to enter and pay some sats for each post. We will have better information here and sats can be used to donate to devs who review PRs related to Taproot. -- Prayank ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
