Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Good morning Peter, > > On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > I like the maxim of Peter Todd: any change of Bitcoin must benefit all > > users. This means that every change must have well-defined and transparent > > benefits. Personally I believe that the only additions to the protocol that > > would still be acceptable are those that clearly benefit layer 2 solutions > > such as LN and do not carry the dangerous potential of getting abused by > > freeloaders selling commercial services on top of “free” eternal storage on > > the blockchain. > > > To strengthen your point: benefiting "all users" can only be done by > benefiting layer 2 solutions in some way, because it's inevitable that the > vast majority of users will use layer 2 because that's the only known way > that Bitcoin can scale. I would like to point out that CTV is usable in LN. In particular, instead of hosting all outputs (remote, local, and all the HTLCs) directly on the commitment transaction, the commitment transaction instead outputs to a CTV-guarded SCRIPT that defers the "real" outputs. This is beneficial since a common cause of unilateral closes is that one of the HTLCs on the channel has timed out. However, only *that* particular HTLC has to be exposed onchain *right now*, and the use of CTV allows only that failing HTLC, plus O(log N) other txes, to be published. The CTV-tree can even be rearranged so that HTLCs with closer timeouts are nearer to the root of the CTV-tree. This allows the rest of the unilateral close to be resolved later, if right now there is block space congestion (we only really need to deal with the sole HTLC that is timing out right now, the rest can be done later when block space is less tight). This is arguably minimal (unilateral closes are rare, though they *do* have massive effects on the network, since a single timed-out channel can, during short-term block congestion, cause other channels to also time out, which worsen the block congestion and leading to cascades of channel closures). So this objection seems, to me, at least mitigated: CTV *can* benefit layer 2 users, which is why I switched from vaguely apathetic to CTV, to vaguely supportive of it. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Good morning Dave, et al., I have not read through *all* the mail on this thread, but have read a fair amount of it. I think the main argument *for* this particular idea is that "it allows the use of real-world non-toy funds to prove that this feature is something actual users demand". An idea that has been percolating in my various computation systems is to use Smart Contracts Unchained to implement a variant of the Microcode idea I put forth some months ago. Briefly, define a set of "more detailed" opcodes that would allow any general computation to be performed. This is the micro-opcode instruction set. Then, when a new opcode or behavior is proposed for Bitcoin SCRIPT, create a new mapping from Bitcoin SCRIPT opcodes (including the new opcodes / behavior) to the micro-opcodes. This is a microcode. Then use Smart Contracts Unchained. This means that we commit to the microcode, plus the SCRIPT that uses the microcode, and instead of sending funds to a new version of the Bitcoin SCRIPT that uses the new opcode(s), send to a "(n-of-n of users) or (1-of-users and (k-of-n of federation))". This is no worse security-wise than using a federated sidechain, without requiring a complete sidechain implementation, and allows the same code (the micro-opcode interpreter) to be reused across all ideas. It may even be worthwhile to include the micro-opcode interpreter into Bitcoin Core, so that the mechanics of merging in a new opcode, that was prototyped via this mechanism, is easier. The federation only needs to interpret the micro-opcode instruction set; it simply translates the (modified) Bitcoin SCRIPT opcodes to the corresponding micro-opcodes and runs that, possibly with reasonable limits on execution time. Users are not required to trust a particular fixed set of k-of-n federation, but may choose any k-of-n they believe is trustworthy. This idea does not require consensus at any point in time. It allows "real" funds to be used, thus demonstrating real demand for the supposed innovation. The problem is the effective erosion of security to depending on k-of-n of a federation. Presumably, proponents of a new opcode or feature would run a micro-opcode interpreter faithfully, so that users have a positive experience with their new opcode, and would carefully monitor and vet the micro-opcode interpreters run by other supposed proponents, on the assumption that a sub-goal of such proponents would be to encourage use of the new opcode / feature. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Hi darosior, Thanks for sharing your thoughts on this. > I would like to know people's sentiment about doing (a very slightly tweaked > version of) BIP118 in place of > (or before doing) BIP119. Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118. > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional > [0], can emulate CTV just fine. For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV? In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY. I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it? Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion. The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo. -- Richard ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson < michaelfolk...@protonmail.com> wrote: > Hi Jorge > > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > > Personally I'd rather stick to one challenge at a time :) Currently we are > facing a contentious soft fork activation attempt of CTV using an > alternative client which we expect [1] to be a Speedy Trial deployment. > Once this is resolved we can discuss the lessons and observations that come > out of this. > That sounds reasonable to me. Fair enough. > > Is there any PR to actively resist the proposal on bitcoin core? > > Not currently. Unless this becomes really, really messy and starts to pose > a true existential threat to Bitcoin itself I think it best that attempts > to actively resist the proposal are done outside of Bitcoin Core in an > alternative client(s). Contrary to what some CTV proponents say getting > anything consensus related into Bitcoin Core is extremely difficult > (especially at short notice). There is no BDFL or Linus Torvalds like > figure, there are a large number of contributors (and maintainers) who all > have differing personal views. Hence directing people to have this > discussion on a particular PR in the Bitcoin Core repo seems to me to be > counterproductive and a massive distraction to other work that is going on > on Bitcoin Core. We've already started to see online attacks on Bitcoin > Core by CTV proponents [2] claiming an "old guard trying to assert > dictatorship over the Bitcoin protocol". It is nonsense of course but > directing that nonsense to the Bitcoin Core repo is surely not the right > way to go. > > As I've said in previous emails there is a Libera (and Freenode now) IRC > channel ##ursf that has been set up to discuss an alternative client. We'll > get a conversation log up too. And of course we wait for confirmation on > what the Speedy Trial deployment parameters for this attempted CTV soft > fork are going to be. > > [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ > [2]: > https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ > > I disagree that it shouldn't be on bitcoin core, but I guess such a proposal would get many nacks. But if there are no speedy trial parameters yet, I guess we need to wait for that; whether the code for resisting it ends up in bitcoin core or not. Thanks for the clarifications. -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > --- Original Message --- > On Saturday, April 23rd, 2022 at 21:40, Jorge Timón > wrote: > > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do > we? > > Is there any PR to actively resist the proposal on bitcoin core? > > > > > > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a >> CTV soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one >> would be skeptical.) >> >> Understandably this has angered and surprised a few people including some >> of those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release >> candidate (and older versions) does not include any CTV code or CTV >> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not >> signal for CTV. If by some chance CTV was to activate through some other >> software release Bitcoin Core releases would not apply CTV rules but they >> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to >> prepare for an eventuality where the miner signaling threshold might be >> reached but the community wants to prevent the attempted soft fork from >> activating. (I personally don't think a 90 percent miner signaling >> threshold will be reached but I wouldn't want to bet Bitcoin's future on >> it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) >> but I'm open to better names. I certainly don't want to discourage those >> who dislike or oppose UASFs from contributing to this effort and >> potentially ultimately running a URSF release. If you don't want this >> rushed CTV soft fork to activate we are all on the same side whatever we >> call it. >> >> For now I've set up a ##ursf channel o
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 2:56 PM Ryan Grant wrote: > Michael and Jorge, > > It is ethically inappropriate to make personal attacks on the > trustworthiness of participants on this list, on such vague grounds as > disliking an activation proposal! > > https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith > I don't think the same principle is being applied to me and other people, sadly. Some people disregard dissent on the grounds that it comes from "people who just loo for dissent". I don't think it is unethical to say the truth. In fact, I think it is fair that I clarify my bias against jeremy. I realize it can be held against me. What I think is hypocritical and unethical is having rules that are only expected to be followed by some. Is everyone assuming good intentions from me? Is everyone assuming good intentions from luke? Is everyone assuming good intentions from michael? I don't think so. It is against the spirit of the project to base your judgements of a > technical solution on who presents them! You should not be so > technically adrift that you only have reputation left to speak about. > I disagree, I think it is against the spirit of the project to trust ideas based on who they come from. In that sense, I apologize for not being able to distrust every other developer as much as I can distrust jeremy. > If you disagree with ideas, then shoot them down on the technical merits. > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html > I've tried regarding bip8 and speedy trial. I may be wrong, but I think those ideas have been discarded not on their technical merits, but based on who were promoting them. I feel there has been a biased against people like Luke-jr or me. That's subjective. Perhaps I'm just being paranoid. But I truly think Jeremy distrusts me and luke as much as I distrusts him, he just won't say it. Anyway, I had said it once before, so I guess there's no need to further disclaim my bias against jeremy. > If you disagree with people, then take it to smuttier sections of the > Internet. > > Yeah, to twitter, right? lol, sorry, I couldn't resist the joke. Sorry. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
You're not even considering user resistance in your cases. You're purely relying on miners and calling speedy trial superior. I don't know if you're being obtuse on purpose, I'm explaining myself very badly... I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO. Sorry for the tone, but, please, make sure you understand that before answering further, or otherwise it is a waste of time. Note that it doesn't have to be in bitcoin core, speedy trial could be used for attempting to activate a controversial softfork (it doesn't need to be an evil fork, even) outside of core. Like what jeremy is trying to do with his proposal, for example. Now, go ahead and tell me that if miners reject it, then doesn't matter, because nobody ever has told me that before, I need to hear it one more time. And I'll tell you I don't care about what miners will do, because you obviously need to hear it one more time as well. Or just tell the list that you resolved all my concerns, like jeremy does about any criticism of his proposals, "well, it has consensus because only people seeking dissent don't like it". Likd with speedy trial. "Some people conplained, but we told them theur concerns were addressed and even though they disagreed and claimed we didn't understand their concerns...it looked like they were seeking dissent, so we told them to f@$k off and now there's consensus". Sorry for the aggressive tone, but I when people ignore some of my points repeteadly, I start to wonder if they do it on purpose. You're not ignoring my points on purpose, are you? Nah, of course not, it's just that communication is hard. Surely it wouldn't be fair if I accused you of being dishonest or pretending to be dumb. Most probably, I'm not clear or direct enough. Whatever the real explanation is for you not understanding me, you're not understanding me and it feels luke a waste of time for both of us. So, I'm sorry, it's over. On Mon, Apr 11, 2022, 14:05 Anthony Towns wrote: > On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev > wrote: > > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote: > > > > Let's discuss those too. Feel free to point out how bip8 fails at > some > > > > hypothetical cases speedy trial doesn't. > > > Any case where a flawed proposal makes it through getting activation > > > parameters set and released, but doesn't achieve supermajority > hashpower > > > support is made worse by bip8/lot=true in comparison to speedy trial > > I disagree. Also, again, not the hypothetical case I want to discuss. > > You just said "Let's discuss those" and "Feel free to point out how bip8 > fails at some hypothetical cases speedy trial doesn't", now you're > saying it's not what you want to discuss? > > But the above does include your "evil soft fork" hypothetical (I mean, > unless you think being evil isn't a flaw?). The evil soft fork gets > proposed, and due to some failure in review, merged with activation > parameters set (via either speedy trial or bip8), then: > > a) supermajority hashpower support is achieved quickly: > - both speedy trial and bip8+lot=true activate the evil fork > > b) supermajority hashpower support is achieved slowly: > - speedy trial does *not* activate the evil fork, as it times out >quickly > - bip8 *does* activate the fork > > c) supermajority hashpower support support is never achieved: > - speedy trial does *not* activate the evil fork > - bip8+lot=false does *not* activate the evil fork, but only after a >long timeout > - bip8+lot=true *does* activate the evil fork > > In case (a), they both do the same thing; in case (b) speedy trial is > superior to bip8 no matter whether lot=true/false since it blocks the > evil fork, and in case (c) speedy trial is better than lot=false because > it's quicker, and much better than lot=true because lot=true activates > the evil fork. > > > > > > 0') someone has come up with a good idea (yay!) > > > > > 1') most of bitcoin is enthusiastically behind the idea > > > > > 2') an enemy of bitcoin is essentially alone in trying to stop it > > > > > 3') almost everyone remains enthusiastic, despite that guy's > > > incoherent > > > > > raving > > > > > 4') nevertheless, the enemies of bitcoin should have the power to > stop > > > > > the good idea > > > > "That guy's incoherent raving" > > > > "I'm just disagreeing". > > > > > > Uh, you realise the above is an alternative hypothetical, and not > talking > > > about you? I would have thought "that guy" being "an enemy of bitcoin" > > > made that obvious... I think you're mistaken; I don't think your emails > > > are incoherent ravings. > > Do you realize IT IS NOT the hypothetical case I wanted to discuss. > > Yes, that's what "alternative" means: a different one. > > > I'm sorry, but I'm tired of trying to explain. and quite, honestly, you > > don't seem interested in listening to me and understanding me at all, but > > only in "a
Re: [bitcoin-dev] Speedy Trial
On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns wrote: > On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote: > > You're not even considering user resistance in your cases. > > Of course I am. Again: > No, you're relying on miners to stop bad proposals. > > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then > > > attempting activation via bip8 is *never* superior to speedy trial, > > > and in some cases is worse. > > > > > > If I'm missing something, you only need to work through a single > example > > > to demonstrate I'm wrong, which seems like it ought to be easy... But > > > just saying "I disagree" and "I don't want to talk about that" isn't > > > going to convince anyone. > > The "some cases" where bip8 with lot=true is *worse* than speedy trial > is when miners correctly see that a bad fork is bad. > > Under *any* other circumstance, when they're used to activate a bad soft > fork, speedy trial and bip8 are the same. If a resistance method works > against bip8, it works against speedy trial; if it fails against speedy > trial, it fails against bip8. > You're wrong. > > Sorry for the aggressive tone, but I when people ignore some of my points > > repeteadly, I start to wonder if they do it on purpose. > > Perhaps examine the beam in your own eye. > Yeah, whether you do that yourself or not: sorry, it's over. > Cheers, > aj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Hi Jorge > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? Personally I'd rather stick to one challenge at a time :) Currently we are facing a contentious soft fork activation attempt of CTV using an alternative client which we expect [1] to be a Speedy Trial deployment. Once this is resolved we can discuss the lessons and observations that come out of this. > Is there any PR to actively resist the proposal on bitcoin core? Not currently. Unless this becomes really, really messy and starts to pose a true existential threat to Bitcoin itself I think it best that attempts to actively resist the proposal are done outside of Bitcoin Core in an alternative client(s). Contrary to what some CTV proponents say getting anything consensus related into Bitcoin Core is extremely difficult (especially at short notice). There is no BDFL or Linus Torvalds like figure, there are a large number of contributors (and maintainers) who all have differing personal views. Hence directing people to have this discussion on a particular PR in the Bitcoin Core repo seems to me to be counterproductive and a massive distraction to other work that is going on on Bitcoin Core. We've already started to see online attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard trying to assert dictatorship over the Bitcoin protocol". It is nonsense of course but directing that nonsense to the Bitcoin Core repo is surely not the right way to go. As I've said in previous emails there is a Libera (and Freenode now) IRC channel ##ursf that has been set up to discuss an alternative client. We'll get a conversation log up too. And of course we wait for confirmation on what the Speedy Trial deployment parameters for this attempted CTV soft fork are going to be. [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ [2]: https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, April 23rd, 2022 at 21:40, Jorge Timón wrote: > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do we? > > Is there any PR to actively resist the proposal on bitcoin core? > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev > wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a CTV >> soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one would >> be skeptical.) >> >> Understandably this has angered and surprised a few people including some of >> those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate >> (and older versions) does not include any CTV code or CTV activation code. >> If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If >> by some chance CTV was to activate through some other software release >> Bitcoin Core releases would not apply CTV rules but they also wouldn't >> reject blocks that apply CTV rules. Hence it is prudent to prepare for an >> eventuality where the miner signaling threshold might be reached but the >> community wants to prevent the attempted soft fork from activating. (I >> personally don't think a 90 percent miner signaling threshold will be >> reached but I wouldn't want to bet Bitcoin's future on it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but >> I'm open to better names. I certainly don't want to discourage those who >> dislike or oppose UASFs from contributing to this effort and potentially >> ultimately running a URSF release. If you don't want this rushed CTV soft >> fork to activate we are all on the same side whatever we call it. >> >> For now I've set up a ##ursf channel on Libera IRC to monitor developments >> and discuss working on an additional release that if run may ultimately >> reject blocks that signal for CTV. >> >> The intention of this would be to provide additional direction and incentive >> to miners that the community does not want this soft fork to be activated. >> To repeat running a Bitcoin Core release will not signal for a CTV soft fork >> out the box. If a miner runs a Bitcoin Core release it will not signal for >> CTV. >> >> Ap
Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
On April 21, 2022 5:10:02 AM GMT+02:00, alicexbt via bitcoin-dev wrote: >@DavidHarding > >Interesting proposal to revert consensus changes. Is it possible to do this >for soft forks that are already activated? > >Example: Some users are not okay with witness discount in segwit transactions > >https://nitter.net/giacomozucco/status/1513614380121927682 That specific case isn't a good example as reverting the discount would actually be a soft fork, as it is a tightening of existing rules. In fact, it'd be a block size decrease. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev wrote: >I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* >users. This means that every change must have well-defined and transparent >benefits. Personally I believe that the only additions to the protocol that >would still be acceptable are those that clearly benefit layer 2 solutions >such as LN *and* do not carry the dangerous potential of getting abused by >freeloaders selling commercial services on top of “free” eternal storage on >the blockchain. To strengthen your point: benefiting "all users" can only be done by benefiting layer 2 solutions in some way, because it's inevitable that the vast majority of users will use layer 2 because that's the only known way that Bitcoin can scale. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 1:12 PM Jorge Timón wrote: > [...all context chopped, mid-sentence...] > I think it is against the spirit of the project to trust ideas based on who > they come from. On this we agree! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Michael and Jorge, It is ethically inappropriate to make personal attacks on the trustworthiness of participants on this list, on such vague grounds as disliking an activation proposal! https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith It is against the spirit of the project to base your judgements of a technical solution on who presents them! You should not be so technically adrift that you only have reputation left to speak about. If you disagree with ideas, then shoot them down on the technical merits. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html If you disagree with people, then take it to smuttier sections of the Internet. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote: > You're not even considering user resistance in your cases. Of course I am. Again: > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then > > attempting activation via bip8 is *never* superior to speedy trial, > > and in some cases is worse. > > > > If I'm missing something, you only need to work through a single example > > to demonstrate I'm wrong, which seems like it ought to be easy... But > > just saying "I disagree" and "I don't want to talk about that" isn't > > going to convince anyone. The "some cases" where bip8 with lot=true is *worse* than speedy trial is when miners correctly see that a bad fork is bad. Under *any* other circumstance, when they're used to activate a bad soft fork, speedy trial and bip8 are the same. If a resistance method works against bip8, it works against speedy trial; if it fails against speedy trial, it fails against bip8. > Sorry for the aggressive tone, but I when people ignore some of my points > repeteadly, I start to wonder if they do it on purpose. Perhaps examine the beam in your own eye. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
