--- Log opened Fri Apr 30 00:00:41 2021
00:57 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack]
01:10 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
01:33 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
01:54 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 252 seconds]
01:57 < AaronvanW> aj: re: consensus. I want to clarify something by making clearer distinctions. IMO: 1) a soft fork requires consensus, otherwise the network could/would split between X and !X. 2) Soft fork *activation* does not require consensus, it just requires that it is as safe as possible (scaffolding). 3) Anything that goes into Bitcoin Core should probably have consensus, for the reason you articulated well. So this applies to
01:57 < AaronvanW>  both soft forks and soft fork activation. 4. Alt-clients can do what they want, whether we like it or not.
01:57 < AaronvanW> (Do you agree with this?)
01:59 < AaronvanW> jeremyrubin: users are shoppers, miners are grocers. developers are not economic actors in the context of the Bitcoin network. (Except to the extent that they are also users or miners.)
02:02 < AaronvanW> luke-jr: would you agree that Bitcoin (Core) users would until October 2022 be better off running LOT=false than no activation method at all? Not asking you to ACK/NACK anything, just an if/then type of question. (Imagine that LOT=true was magically unavailable for some users.)
02:10 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
02:11 <@aj> AaronvanW: if you don't have consensus on activation, you don't have consensus on the soft fork that's being activated -- everyone needs to know what rules apply at block X+1 in order to validate it
02:12 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
02:13 <@aj> AaronvanW: you can be much more accepting of weird rules about activation than for the things they activate, because the activation rules can be temporary while the things being activated are usually permanent though
02:14 < AaronvanW> aj: that would be ideal. but what we're really trying to achieve with a soft fork is that the network doesn't split, and some users can upgrade can upgrade later. right?
02:17 < AaronvanW> *with soft fork activation
02:23 < AaronvanW> You say "much more accepting". I'm wondering if there is a !X for this X. If miners would comply with LOT=true, are there any users that *hate* LOT=true so much that they would deploy a counter-LOT=true and split the network? (Why?)
02:23 < AaronvanW> The above is true for soft forks, I'm sure. But for soft fork activation?
02:25 < AaronvanW> The above is true for contentious soft forks, I'm sure. But for soft fork activation (LOT=true)?
02:27 <@aj> AaronvanW: lot=true splits off if there isn't a period where 90% of miners signal on the chosen version bit between startheight and stopheight. it's possible the economic majority might decide to activate taproot via some method that doesn't require that signalling. it seems likely that >10% of miners won't bother to setup signalling to satisfy lot=true, and the remaining <90% won't bother
02:27 <@aj> orphaning those blocks, just to satisfy an alternative way of activating something that's already active, eg.
02:29 <@aj> AaronvanW: one reason to do that would be to avoid people thinking there's a first mover advantage "oh, if we deploy a client with our favourite rules first, then everyone else will have to adopt them even if we're a trivial minority" -- because if that were an effective strategy it would encourage people rushing to deploy consensus changes, rather than taking time to review them
02:30 < AaronvanW> I understand this. My question is, if >90% of miners *do* comply with LOT=true and signal, do you think we will see a network split because some users will actively reject the LOT=true activation?
02:31 < AaronvanW> I'm talking about an otherwise non-contentious soft fork, eg Taproot.
02:34 <@aj> if it's non-contentious, lot=true is irrelevant
02:35 < AaronvanW> What does "it" refer to? Taproot or LOT=true? Taproot, right?
02:36 <@aj> "activation of taproot"
02:41 < AaronvanW> non-contentious among whom exactly? Am I right that you are including miners in this?
02:42 < AaronvanW> (Either you don't understand my question, or you do, and I don't understand your answer.)
02:43 <@aj> "<AaronvanW> I'm talking about an otherwise non-contentious soft fork,"
02:43 <@aj> if the fork's non-contentious it gets activated by ST straight away
02:43 <@aj> modulo some time for upgrading
02:43 < AaronvanW> when I say "non-contentious", I'm referring to users. miners aren't part of the equation here. I think you might disagree?
02:44 <@aj> miners are are users...
02:44 < AaronvanW> Right, so this is where we disagree. (Also recalling one of your dev-list emails now.)
02:45 <@aj> they receive bitcoin when they mine, then probably spend it to pay for electricity or new hardware or lambos
02:45 < AaronvanW> In my view, miners aren't part of consensus. Users define the (consensus) rules, miners mine within them.
02:45 <@aj> how could they possibly not be users?
02:45 < AaronvanW> Whether it's "bitcoin" that they are mining or something else, is defined by users.
02:46 < AaronvanW> the people accepting it for electricity or lambos, they decide if the "bitcoin" they receive are indeed valid bitcoin.
02:51 <@aj> in the case of a a block race, like https://twitter.com/BitMEXResearch/status/1384239888908701703 ; which of the colliding blocks' coinbases become valid bitcoins is precisely decided by which block other miners build on top of; so miners fulfil that definition
02:52 <@aj> i think "you're only a user if you're actively participating in bitcoin consensus development" is backwards though
02:53 < AaronvanW> aj: users define the rules, miners order transactions (block race)
02:53 <@aj> perhaps a more accurate fit for what you're getting at is: miners accept bitcoin from other people the same way lambo dealers do -- they're just looking for valid btc tx's that have funds left as fees, as opposed to the lambo dealers who are looking for their specific address in an output. either way they're still trying to accept valid bitcoins in much the same way
02:54 < AaronvanW> just to be clear: are you aware of "my" perspective and disagree with it, or did you not realize that many people see it this way. (because this is not a fringe view.)
02:55 <@aj> AaronvanW: if you're really arguing that people who mine aren't bitcoin users and their opinions about what consensus should be doesn't matter, i think you're crazy...
02:55 < AaronvanW> wow
02:56 <@aj> wow because you are saying that?
02:57 < AaronvanW> to be clear I very much respect the dialogue. I believe that what I'm saying is a very mainstream perspective. AFAIK very prominent Core devs agree with me on this.
02:58 < AaronvanW> (or I agree with them...)
02:58 <@aj> so blockstream has a mining operation, should we ignore they're opinion on what consensus should be? i think greg maxwell has some miners, should we ignore his opinion?
02:58 <@aj> their
02:59 < AaronvanW> Yes. Ask them. I believe they will tell you the same thing :)
02:59 <@aj> why would i ask them if their opinion doesn't matter?
02:59 < AaronvanW> To be clear: their perspective as *users* matters.
03:00 <@aj> that's not clear at all
03:00 < AaronvanW> Alejandro reached out to eg Adam Back to ask about their opinion on Taproot. He refused to answer for this exact reason. Not relevant. (I'm paraphrasing, feel free to check.)
03:00 <@aj> are you just trying to say "you don't get/deserve any special privileges because you're a miner" ?
03:01 <@aj> is this some weird language thing?
03:02 < AaronvanW> I'm also saying: if your argument for/or against a consensus change only affects miners, it doesn't matter. Eg. that's why a PoW hard fork is available as a "nuclear option" if users think the miners are misbehaving. Miners would of course never agree with that. Yet it's an option.
03:03 <@aj> take Alice, Bob, Carol, Dave; Alice's full time job is running a mining farm; Bob's CFO at blockstream and manages finances for devs and satellites and mining; Carol sells lambos for BTC; Dave helps onboard other people into BTC and takes 2-and-20 or whatever; they all have some significant percent of their savings in BTC, all have studied the proposals and considered the consequences and possible
03:03 <@aj> alternatives.
03:04 <@aj> i'd say all their opinions are roughly equally important (and if the've got novel, rational arguments in favour of their opinions, that's more important)
03:05 < AaronvanW> Does Alice's her opinion affect users, or only her mining efforts? If the latter, it's not something users have to take into account for consensus.
03:07 < AaronvanW> eg. Alice may say: "We shouldn't do a PoW hard fork because that will make my ASICs worthless." Then users can respond by: "Tough luck, that only affects miners, not part of consensus."
03:07 <@aj> if you change the PoW algo, that renders all the ASICs for the old PoW obsolete (assume you've solved all the upgrade problems) -- but then, where do you get ASICs for the new PoW from? does someone monopolise production early, and essentially become 80% of hashpower? do people decide they don't want to invest in ASICs since they might just lose their investment? (do we get more attacks on CI
03:07 <@aj> infra as people try to CPU/GPU mine using other people's electricity/hardware?)
03:07 < AaronvanW> not the point
03:08 <@aj> "Dave may say, this breaks my setup and I won't be able to sell lambo's anymore" do we just say "lambos suck, you're not part of consensus"
03:08 < AaronvanW> no
03:08 < AaronvanW> Dave is a user.
03:08 <@aj> sorry, Carol
03:08 < AaronvanW> Carol too
03:08 <@aj> yeah, you're picking winners at this point
03:09 < AaronvanW> aj I promise you this is a very mainstream perspective.
03:09 <@aj> that's exactly why i think miners could conceivably decide "you guys want a war" -- you don't care about sending them bankrupt
03:09 < AaronvanW> that's not true.
03:10 <@aj> "Tough luck, that only affects miners"
03:11 <@aj> i mean "bitcoin is a stupid waste of energy" is a very mainstream perspective; that a perspective is mainstream doesn't mean it's not dumb
03:11 < AaronvanW> Miners are employers of the network. Sometimes the analogy with security guards is used. Security guards are important. They are paid well. We don't hate them. But if users decide to move to a new building, then security guards will have to follow (or not get paid anymore).
03:13 <@aj> "employees"
03:13 < AaronvanW> aj This is a mainstream perspective among Core devs. Please ask around. gmaxwell, BlueMatt, sipa, luke-jr... etc, I don't want to speak on their behalf, but I'm pretty sure they share this perspectve.
03:13 < AaronvanW> Adam Back
03:16 <@aj> AaronvanW: suppose you have a business, with an office, that employs security guards, just as you suggest
03:16 <@aj> AaronvanW: there's a question as to whether they want to move offices
03:16 <@aj> AaronvanW: the business tries to be "open source" and "consensus" driven. who makes the decision?
03:17 <@aj> AaronvanW: your argument seems to be "all the employees except for the security guards" ?
03:17 < AaronvanW> More like, Bitcoin has replaced the CEO with users.
03:17 <@aj> AaronvanW: but perhaps it's "the shareholders" in which case my claim is "the security guards are share holders too"
03:19 <@aj> AaronvanW: (if said security guards sold all their stock options, then fine, they don't get a say -- just as miners who're switching between BTC and BCH and immediately selling as soon as they can likely don't get a say in BTC)
03:19 < AaronvanW> all users have a say, but their opinion is only valid if it affects users. (users = people who accept bitcoin for payment)
03:19 <@aj> like i said above, miners, by mining, accept bitcoin for payment (their service is transaction ordering, their payment is transaction fees)
03:20 < AaronvanW> No they don't because user consensus defines if it is "bitcoin" that they accept or not.
03:21 < AaronvanW> *that they mine
03:23 <@aj> "user consensus defines it is is "bitcoin" that they accept or not" <-- that's true for everyone, miner or not
03:24 < AaronvanW> yes. users give value by accepting coin in exchange. agreed?
03:27 <@aj> that's the supply side; if you add the demand side as well (not being willing to give away coin for insufficient value), sure
03:27 <@aj> (swap supply/demand if you're looking at it from the coin side rather than the goods/services side i guess)
03:30 < AaronvanW> miners are basically selling security/block space, agreed?
03:37 < jnewbery> AaronvanW: I'm struggling to understand how you can claim that miners aren't users. By your definition "people who accept bitcoin for payment", they certainly are users. They're selling hashrate and getting Bitcoin in exchange.
03:38 <@aj> selling block space for fees, and selling proof-of-work for subsidy-plus-fees, yeah
03:38 < jnewbery> They're not the only users, and they don't have special rights over other users, but they're users like anyone else who is accepting bitcoin for payment.
03:42 < AaronvanW> I'm trying to fund a more long-form article explaining this, maybe that's better. The sad thing is that eg. gmaxwell doesn't do blogs but Reddit posts which are near-impossible to find ;) But here's an explanation from Voskuil: https://github.com/libbitcoin/libbitcoin-system/wiki/Balance-of-Power-Fallacy
03:43 < AaronvanW> (I think Voskuil wrote a bunch of these, this is just the first I could find.)
03:46 <@aj> AaronvanW: https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy is i think a criticism of the argument you're making
03:47 < AaronvanW> aj: well what if no one wants their block space or hash power because everyone's moved to a new protocol? then miners aren't accepting anything in exchange, because there is no one to exchange with, right?
03:48 <@aj> AaronvanW: if everyone went to BCH, they'd still be accepting BTC even if there were no transactions via the block subsidy
03:50 <@aj> AaronvanW: (except likely there would be txs, same as there's still a handful of txs on ETC)
03:50 < AaronvanW> Not if everyone would consider BCH to be "BTC".
03:51 <@aj> AaronvanW: even if _everyone_ considered BCH to be "the real bitcoin", miners producing BTC blocks would still receive BTC via the subsidy. that's true even if no one wanted to buy that BTC even for 1/21millionth of a cent
03:52 < AaronvanW> Do you agree that Bitcoin can hard fork? Or do you disagree?
03:53 <@aj> I don't know; I hope it can
03:53 < AaronvanW> I guess you would say Bitcoin can hard fork, but it requires consensus from everyone including miers?
03:53 <@aj> I'd consider it to be a successful hard fork if the hardfork retained >80% of the value of pre-fork BTC
03:54 < AaronvanW> So then a better question is, do you believe Bitcoin can hard fork to a new PoW if miners attack the network? (And miners oppose the hard fork.)
03:55 < AaronvanW> I'm not asking if it's desirable, I'm asking if it's technically possible, so to say.
03:55 <@aj> Eh, that's complicated; how about we just assume it's possible for the sake of argument?
03:57 < AaronvanW> Then these attacking miners that don't switch to the new chain, but they keep mining. What are they mining?
03:57 <@aj> Like: we have a new ASIC design for the new PoW, that's public domain and unpatented and can be constructed cheaply by multiple fabs in different jurisdictions and shipped out to people without high profit margins with low delay, the reason to switch to new PoW is clear and obvious and >80% of people want to switch and there's clear market signals that everyone will shift, and all the technical
03:57 <@aj> issues have been well studied by a variety of people who all conclude that it makes sense
03:58 <@aj> they're mining BTC-OLD but not BTC-NEW, or whatever the two chains happen to end up being called
03:58 <@aj> ETC/ETH, BTC/BCH, BT1/BT2, whatever
04:02 < AaronvanW> Well that's kind of the important part, not the "whatever" part :)
04:03 <@aj> ?
04:03 <@aj> picking a name is always the "whatever" part
04:04 < AaronvanW> I'd say a hard fork requires 100% consensus (not 80), but miners aren't part of this consensus. So if 100% of users agree to hard fork, the new chain is "Bitcoin". Miners can keep mining themselves into bankruptcy on the old chain if they insist. (I don't think this is a fringe view.)
04:05 <@aj> anyone can do a hard fork at any time, on their own -- all the 2017 forks demonstrated that
04:05 <@aj> definitely no need for 100% consensus
04:05 < AaronvanW> yep, all without 100% consensus.
04:05 < AaronvanW> that's why they're not "Bitcoin".
04:07 <@aj> if you're worried about the name, BCH-ABC vs BCH-SV is the easiest example -- hard forks without consensus, eventually ABC won the battle for the old name with ~75% of the value
04:08 <@aj> if you ask adherents of either, they'll assure you that their coin is most-definitely "Bitcoin" though
04:08 < AaronvanW> ever wondered why these coins are such shitshows? it's because they hadn't figured out these kinds of governance questions
04:08 < belcher> right, exchange rate is convincing but it doesnt convince _everyone_, some still continue to use the name bitcoin for those small airdrops
04:09 <@aj> no, i haven't wondered why they're such shitshows -- they make terrible technical decisions, and spend all their time on propaganda...
04:09 <@aj> but even with that, they still get mined, and they still have names that people can use to refer to them
04:10 < AaronvanW> yes, but not "Bitcoin".
04:12 <@aj> if s2x had won the popularity contest, the current chain would be "bitcoin OG" or something instead
04:12 < AaronvanW> No, it would be Bitcoin. Because there was no consensus for 2X.
04:12 <@aj> but the current chain got 80% or so of the future's market, so s2x died stillborn
04:13 <@aj> if that were the case, "ETC" would be ethereum, not the hard fork
04:13 < AaronvanW> see, that's the difference between Bitcoin and Ethereum.
04:14 < AaronvanW> Ethereum has proof of vitalik.
04:14 < AaronvanW> Bitcoin is decentralized.
04:14 < AaronvanW> The Ethereum Foundation literally trademarked the name Ethereum. They decide.
04:14 < belcher> names are subjective
04:15 < AaronvanW> Not for Ethereum.
04:15 < belcher> like prices... everyone chooses names for themselves, in bitcoin we're in a nice situation that nearly everyone calls this thing "bitcoin" but there is a small minority that use the name "bitcoin" for BCH-ABC or BCH-SV
04:16 < AaronvanW> I'm aware. I'm explaining "my" perspective (what I would consider to be Bitcoin), but I don't believe this is a fringe perspective.
04:16 < belcher> yes
04:16 < belcher> how did we get onto this names thing again /me reads up
04:17 < belcher> oh the PoW hard fork
04:17 < belcher> iv found this article convincing for why a PoW hard fork wont ever be that useful https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy
04:18 < AaronvanW> belcher: are miners also users? or are they different. I say: users define the consensus rules, miners order transactions.
04:18 < belcher> i agree but it might be more helpful to use the word "acceptor" or maybe "merchants" rather than users
04:18 < AaronvanW> belcher: is this a fringe perspective in your view?
04:18 < belcher> the people that control the rules are those who use full node wallets to accept bitcoin, they have the power to say "sorry your money is no good here"
04:19 < belcher> AaronvanW its popular, but i still reckon the word "users" is slightly confusing (though in most cases it makes no difference)
04:19 < AaronvanW> that's fair!
04:19 < belcher> and nobody really started using "acceptors" :p
04:20 < AaronvanW> I believe that this debate is a huge part of what the block size wars were about, and the Bitcoin community more or less settled on this perspective. would you agree with that?
04:20 <@aj> belcher: "bitcoin's demand-side" perhaps?
04:20 < AaronvanW> that would include Core devs etc.
04:20 < belcher> aj yeah but not for sending, only receiving (demand-side could imply bitcoin as a medium of exchange which involves both)
04:21 <@aj> belcher: using btc as a medium of exchange involves validating incoming transactions though?
04:21 < belcher> right
04:22 <@aj> belcher: "bitcoin savers" if you only want SoV users i guess, but that also seem a bit picking-winners
04:23 < belcher> id say all acceptors rather than just savers (though savers are surely an important part if they use full node wallets when they add to their stack)
04:24 < belcher> this section explains the idea as well https://en.bitcoin.it/wiki/Full_node#Economic_strength
04:24 <@aj> suppose Jan 1st, Alice and Bob have 0 BTC. Alice starts mining. Bob starts selling lambos. At the end of March, both Alice and Bob each have 60 BTC after paying their setup and ongoing costs. they both decide this has been fun, and keep their 60 BTC as long-term savings and continue with the mining & lambo businesses respectively
04:24 < belcher> theres also a link to a reddit post by sipa
04:24 <@aj> AaronvanW: in the above case, do you distinguish between alice and bob?
04:25 < belcher> in that example alice is acting both as a miner and acceptor (and saver)
04:25 < belcher> both roles within one person
04:25 < AaronvanW> ^^
04:26 <@aj> AaronvanW: is that a "no" ?
04:26 < AaronvanW> a typo actually, one sec.
04:26 < belcher> almost all people in the world are doing something like this so it still makes sense to consider their view when trying to find consensus about something
04:28 < AaronvanW> I agree with belcher. And he's explaining it better than I did before. (That's another way of saying I was explaining it wrong before.)
04:28 <@aj> belcher: (oh, "yeah but not for sending, only receiving" -- how do you send without having received first?)
04:29 <@aj> AaronvanW: that doesn't answer my question though?
04:29 < belcher> aj the sending and receiving might be disconnected in time, so maybe you received 5 years ago and then you had power over the rules, and when you spend today you dont have power at that point
04:29 < AaronvanW> aj: I don't, but I would distinguish between potential arguments they might make.
04:30 <@aj> AaronvanW: if alice says "taproot is bad because it hurts my business" and bob says "taproot is bad because is hurts my business" would you distinguish between those responses?
04:31 <@aj> i mean apart from telling bob he meant "it" not "is"...
04:32 <@aj> belcher: i think you'd only care in either case if they were planning on doing it repeatedly in the future?
04:32 < belcher> i guess
04:32 <@aj> belcher: if it's a one off "i'd like to receive this bitcoin payment" or "i'd like to cash out of bitcoin", it doesn't much matter?
04:32 < AaronvanW> I do think you are making a good point aj. I need to run to the store anyways, so let me think about this for a few minutes.
04:32 <@aj> AaronvanW: okay, bonus thought then:
04:33 <@aj> AaronvanW: what if it was a trick question, and alice was mining gold? or mining ethereum? much more like selling lambos in that it's unrelated to bitcoin consensus rules. should her opinion matter more if she does less bitcoin things?
04:50 < belcher> aj one way of saying it would be imagine if gold miners decide they want to use their equipment to mine copper instead, saying copper is easier to mine so they'll just do that, suppose they get the metal exchanges to agree.. that all sounds fine except the problem is the people buying the gold want actual gold not copper
04:50 < belcher> (i know the analogy falls down because gold mining and copper mining are pretty different, but ignore that for this)
04:51 < queip> copper and gold, or probably more copper and silver, are merge-mined :)
04:53 < belcher> doesnt gold require loads of mercury but copper is not?
05:19 <@aj> belcher: people buying gold already tend to do tests on it as i understand, so it'd probably be pretty hard to pass off copper as gold...
05:21 <@aj> belcher: a different analogy that might work is mined diamonds vs artificial diamonds; https://frankdarling.com/7-reasons-not-to-buy-a-lab-grown-diamond/
05:24 < AaronvanW> aj: thanks (again) for engaging with me on this. you're challenging my assumptions, and are forcing me to more clearly what I mean when I say "user".
05:24 < AaronvanW> I think in the context of Bitcoin, a user is basically a holder.
05:25 < AaronvanW> The "accepting bitcoin in exchange" part is overemphasized. "Accepting bitcoin in exchange" is just the moment someone starts holding.
05:26 < AaronvanW> I believe that bitcoin derives its value from the demand to hold it.
05:27 <@aj> i believe bitcoin derives its price from the demand to hold it; but there's also value in making it more useful as a MoE (ie, making lightning work better, and the like)
05:29 <@aj> ie, everyone decided to hold 20% of their savings as bitcoin vs stocks or property -- that determines bitcoin's price; but having an anyone-can-participate replacement for "sorry you can't bank with us" credit card merchant services is valuable too
05:30 < AaronvanW> yes, but what users care about is best distilled in the value of the coin going up. (I'm not saying this is something I want, I'm saying this is something users in aggregate want.)
05:30 < AaronvanW> so to answer your question, I don't think users care about anyone's business.
05:31 < AaronvanW> if a protocol change destroys a business but makes the value of a coin go up, I think they will want it.
05:32 < AaronvanW> whether it's a mining business, or a lambo business, or a chainalysis business.
05:32 < AaronvanW> if improving privacy on the base layer bankrupts someone's chainalysis business, users in aggregate will want it I think.
05:33 <@aj> AaronvanW: i think you're defining "users" as "people who only care about bitcoin as a SoV" there, which isn't a natural reading
05:33 < AaronvanW> I am.
05:33 < AaronvanW> Not because I want it, but because I think that's what it is.
05:33 <@aj> AaronvanW: i think someone who uses bitpay to accept bitcoin payments and immediately convert them to fiat would consider themselves a bitcoin user
05:35 < AaronvanW> I think users will adopt whatever they believe will make the value of their coin go up. I repeat, this is not what I necessarily want to happen, I think this is what will happen.
05:36 <@aj> so, i think hodlers are .. 90% to 99% of bitcoin's value prop, so i'm not really disagreeing... just that my motivation for getting into bitcoin was the lightning/MoE/"p2p cash" use case...
05:36 < AaronvanW> So if Bitcoin Core doesn't recognise this, because a different interpretation of "user" is used when designing protocol upgrades, I think Bitcoin Core might be replaced as the reference implementation.
05:36 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
05:37 < AaronvanW> That doesn't mean you need to.
05:37 <@aj> if that's what you want to say, i think you should call the people hodlers not users though
05:37 < AaronvanW> Bitcoin Core should obviously do what it thinks is best. It's just that that is what I expect would happen.
05:37 <@aj> (or savers or holders or whatever if hodler is too gimmicky)
05:38 < AaronvanW> I think it's 100%. Everything else only matter to the extent that it benefits the value of the coin.
05:39 < AaronvanW> (Or harms the value of the coin.)
05:39 < AaronvanW> If enough people benefit from eg. Lightning, then Lightning benefits the value of the coin.
05:41 < AaronvanW> If enough people benefit from privacy, then privacy tools will benefit the value of the coin. etc
05:43 < AaronvanW> To make this concrete, I think Taproot will benefit the value of the coin. I don't think activating it through LOT=true (if necessary) will harm the value of the coin.
05:44 < AaronvanW> Therefore I expect that it will happen. Either through Core, or through an alt-client.
05:44 <@aj> AaronvanW: hmm, i thought i did a blog post or something with the numbers. my recollection was that having a good SoV was worth something like x trillion dollars, and that replacing the credit card companies was worth maybe 5% of that, but i can't really remember
05:47 <@aj> AaronvanW: if it's a 20:1 ratio like that, then a change that loses 1% of the value of the coin for a 5x or 10x improvement as method of exchange might still be worthwhile in a "makes the world a better place" sense or in a "people will be more willing to fight for it than against it" sense. but while we're early, everything that improves adoption in any sense will probably win on every metric
05:47 <@aj> anyway
05:49 < AaronvanW> One question you could ask is, will an "evil soft fork" (eg censorship fork) ever be able to make the value of the coin go up?
05:49 -!- CARO1 [~Cesar@2804:7f4:c1a0:f570:9424:92ed:d61d:da7f] has joined ##taproot-activation
05:50 -!- CARO [~Cesar@2804:7f4:c29d:4d83:7c3a:c9c7:c1a3:9e77] has quit [Ping timeout: 260 seconds]
05:51 < belcher> AaronvanW maybe if it results in more normie money flooding in because now bitcoin would be "compliant"
05:51 < belcher> its really interesting you see users (as in user-activated-soft-fork) as hodlers, i disagree but it helps me understand why for example you put so much emphasis on futures markets
05:52 < belcher> i always understood users to be acceptors, those who use full node wallets to accept bitcoin in exchange for something and therefore have the power to say "sorry your money is no good here"... it seems like they are the only ones who protect rules such as the 21 million limit
05:52 < AaronvanW> 'maybe if it results in more normie money flooding in because now bitcoin would be "compliant"' <--- yep, seems like a very important question
05:53 <@aj> AaronvanW: https://github.com/BitcoinActivation/bitcoin/pull/7 was the PR that merged the lot=true feature for the alt client, and https://github.com/BitcoinActivation/bitcoin/pull/9 was the PR that set the activation parameters. does that level of review, accompanied with failing CI indicators not seem like something that might impact the price negatively to you?
05:53 < belcher> i dont see how coins sitting in cold storage not moving do anything to protect rules like the 21 million limit
05:53 < AaronvanW> (that's pretty much why my pinned tweet is my pinned tweet, btw.)
05:54 < AaronvanW> https://twitter.com/AaronvanW/status/1138423259400155136
05:56 < AaronvanW> aj: I don't know if I know what the market cares about. I do know that efficient markets require perfect information, and most users have no idea what the thing you linked to is.
05:56 < belcher> the truth will come out eventually
05:56 < AaronvanW> belcher: it's about demand to hold.
05:57 < AaronvanW> the fact that people are holding means they have demand to hold. otherwise they'd sell.
05:58 < AaronvanW> aj: and note that the LOT=true client just launched. there's time to improve in all sorts of ways, before it needs to become relevant.
05:58 <@aj> AaronvanW: the time to do review is prior to a merge, especially if the entire reason for your fork is that patch
05:59 < belcher> AaronvanW demand to hold doesnt enforce the rules, it just changes the exchange rate
06:00 < AaronvanW> aj: do users care?
06:00 < AaronvanW> belcher: the rules are still enforced at the moment of exchange (the moment you start holding)
06:01 < AaronvanW> if the rules change during holding, demand to hold might disappear, and users would sell.
06:01 < belcher> you know bitcoin unlimited and other fork clients also seemed to have the view that technical matters arent really important, one of the results was the segwit2x off-by-one error which froze their chain
06:01 < AaronvanW> eg how many people sold their BCH.
06:01 <@aj> AaronvanW: if they didn't, then why isn't BCH doing better, for example? it has the same 21M cap
06:02 < AaronvanW> belcher: I'm not saying technical matters aren't important, I'm just not sure users care when a first merge was done exactly, especially if they'll only start using the client in a year or so.
06:03 < belcher> i hope they do care otherwise bitcoin might just die because of some bug
06:03 < belcher> im pretty sure they will care when its their own money on the line
06:03 < AaronvanW> aj: BCH (like every other altcoin) violates the original 21M cap.
06:03 < AaronvanW> belcher: the question is if developers will care about what users want. if not, yes Bitcoin might die.
06:03 < AaronvanW> brb call
06:04 <@aj> AaronvanW: by that logic you're claiming bitcoin can never hard fork
06:04 < AaronvanW> aj: pretty much, unless with 100% consensus, because then the original 21M is truly replaced/maintained.
06:04 < AaronvanW> sorry call :)
06:16 -!- cec43 [aedb0b09@9.sub-174-219-11.myvzw.com] has joined ##taproot-activation
06:20 -!- cec43 [aedb0b09@9.sub-174-219-11.myvzw.com] has quit [Client Quit]
06:48 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]
07:22 < AaronvanW> (To be clear, when I say Bitcoin might die, I don't mean this year or next year or because of LOT=true or not, I mean it more in the sense of -- what I think would be -- a long-term non-viable path.)
07:23 < belcher> i dont see how bitcoin would die, wouldnt users just adopt software made by different developers?
07:23 < luke-jr> Bitcoin can die if users allow it to
07:24 < AaronvanW> if different developers step up to the plate yes. I'm not sure how easy or viable that is? I think that's also what Amir refers to on the mailing list just now.
07:25 < belcher> amir seems to want elections lol
07:26 < belcher> "The community is free to elect their preferred version of Bitcoin." to that id say if you want money controlled by elections you can already use the USD (though possibly im misreading him)
07:26 < AaronvanW> elect doesn't literally mean elections.
07:26 < AaronvanW> just, choose which software they want to run. individually.
07:26 < belcher> right
07:26 < belcher> thats always been the case
07:27 < belcher> amir talks about a "fully specced standard", but theres nothing stopping him trying to write one down on paper... he'll probably find if he did that its quite hard to do
07:28 < AaronvanW> that's why he's asking experts to do it, is my interpretation.
07:28 < belcher> its always easiest to beg other people to do stuff for you
07:29 < AaronvanW> btw I'm not saying I necessarily agree with him, or with everything he wrote. I just think he's seeing a problem, and proposes a solution. I don't know if that is *the* solution.
07:29 < belcher> it turns out people who want to contribute development resources usually find it better to cooperate with other developers rather than being antagonistic, that seems to be why they coalesce around one open source project
07:30 < AaronvanW> I understand.
07:32 < mol_> Amir's responde to someone named James Caring and Caring is not a bitcoin user, he said he's using an alt coin
07:33 < AaronvanW> belcher I know you think people are being antagonistic, I think that's a misunderstanding.
07:35 < belcher> i know you're not AaronvanW, other people are i think for example bitcoinmechanic, when talking to him i got the impression he wants the perceived bitcoin core monopoly to be broken... for me i see bitcoin core just as a group of developers who voluntarily cooperate, breaking that just means breaking up their cooperation which is antagonistic
07:35 < AaronvanW> quoting myself from earlier today icymi:
07:35 < AaronvanW> 07:48 AaronvanW: so maybe there's two categories of LOT=true proponents. (or rather, two extremes.) one category just wants Taproot. the other category just doesn't want miner veto. but I don't think either wants war. (we could probably further subdivide into LOT=true'ers that want LOT=true in Core, and LOT=true'ers that want LOT=true in an alt-client to avoid the perception of dev control. But I digress.) "We don't w
07:35 < AaronvanW> ar, but if you wa
07:35 < AaronvanW> 07:48 AaronvanW: nt war, you'll get war" is probably a fair characterization of some of them. "We just want war," really isn't, as far as I can tell. If that's a perception, and if that perception is really the problem/risk, it would be good if that perception could somehow change.
07:35 < belcher> i would have thought bip148 which was released outside core proved that the consensus-finding method of bitcoin core isnt enough to stop rule changes
07:36 < AaronvanW> oh you mean antogonistic against developers? (I was talking about miners.)
07:36 < belcher> another reason i got that impression was from talking to brg444 about two months ago, i said lot=true is a bad idea because people like bluematt are against it, and he replied "oh so we're going to let a few devs stop an update?"... to that my answer is well yes if they have good technical arguments
07:39 < AaronvanW> I'm painting with broad strokes here, but I think developers think of themselves as "smart users" (and they are), and therefore they view the Bitcoin Core process as the best possible reflection of what users want. I assume absolutely no ill-intent here, I think developers do what they think is what's best for Bitcoin and Bitcoin users, but I'm really not sure that this assessment is correct, in part for reasons I've
07:39 < AaronvanW> been discussing in this chat today.
07:40 < AaronvanW> (even if it's correct 99% of the time, which it may well be, that 1% could still be a big deal.)
07:42 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
07:45 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 252 seconds]
07:49 -!- J[m]3 [jlich10mat@gateway/shell/matrix.org/x-syucokmooomouzin] has joined ##taproot-activation
07:50 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
07:55 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation
08:13 < AaronvanW> Quoting Rusty: "We should be concerned about about future corruption, insanity, or groupthink." https://rusty.ozlabs.org/?p=628
08:14 < AaronvanW> Rusty has like, 30(?) years of open source experience, he's seen this kind of stuff happen.
08:23 < belcher> yep its a valid concern
08:50 < AaronvanW> As for something like BIP148, I don't think it was saying: "Fuck these Core devs, we're going to fire them, disrupt their consensus process, and take over this party." Rather, it was saying: "Wow, Segwit looks fantastic, thanks developers! Now, we understand that you're in an awkward position here, because if you're perceived to control the protocol rules, it might result in you literally getting death threats in the
08:50 < AaronvanW> future. So we're gonna step in for one quick sec, activate this thing, and then please continue your amazing collaborative work."
08:51 < belcher> ^ agreed with this
08:51 < AaronvanW> I of course don't know what motivates individuals, but I'm also not sure it really matters on a technical level?
08:51 < belcher> iirc some individual core devs actually helped out with bip148, like didnt wumpus sign the releases?
08:51 < AaronvanW> yes
08:52 < AaronvanW> although he also made clear that shouldn't be considered an endorsement of it.
08:52 < AaronvanW> that's how I remember it anyways.
08:52 < belcher> yep
09:02 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
09:23 < luke-jr> most devs supported BIP148
09:24 < jonatack> AaronvanW: friendly cherry picking on a phrase that randomly caught my eye: "they view the Bitcoin Core process as the best possible reflection of what users want", I think in some cases it's quite difficult to interest reviewers in (some) things that might be useful to users but that aren't particularly prestigious or interesting to review from a protocol or dev point of view.
09:25 < belcher> luke-jr if most devs supported bip148 and therefore it was fine, then ST should be fine as well because most devs support it, right?
09:25 < AaronvanW> good point jonatack
09:25 < luke-jr> belcher: devs don't decide protocol rules
09:25 < belcher> "most" is still not "consensus", bitcoin core didnt have consensus for bip148 https://gist.github.com/chris-belcher/a8155df5051bb3e3aa96#the-core-developers-did-not-have-consensus-in-favour-of-the-uasf-yet-it-still-happened
09:26 < luke-jr> yes, ST shouldn't have been merged for the same reasons BIP148 wasn't merged
09:26 < luke-jr> BIP148 was closer (merely lacking dev consensus) than ST at meeting the criteria
09:29 < AaronvanW> btw aj "if it's a 20:1 ratio like that, then a change that loses 1% of the value of the coin for a 5x or 10x improvement as method of exchange might still be worthwhile in a "makes the world a better place" sense or in a "people will be more willing to fight for it than against it" sense." <---- maaaybe? I'm more inclined to think that these things will just make the value go up. But it's an interesting point either w
09:29 < AaronvanW> ay.
09:30 < belcher> in order to stop luke doing what i consider rewriting history, have a look at the chatlogs of bitcoin-core-dev from a meeting where it was discussed http://gnusha.org/bitcoin-core-dev/2021-04-14.log (ctrl+f "NACK") luke was asked for _evidence_ that BIP8 has consensus but ST doesnt have consensus and he couldnt provide an answer
09:30 < luke-jr> belcher: now you're just trolling
09:31  * belcher sigh
09:31 < belcher> this debate has been had many times before theres no point going over it again, but if you do have evidence this time feel free to post
09:32 < belcher> i can show you my evidence: poll with 1300 respondents https://twitter.com/AaronvanW/status/1384205266737004558 and another poll where bitcoinmechanic disagreed with the wording which result show most support for ST https://twitter.com/GrassFedBitcoin/status/1384238795332087809
09:32 < belcher> also my one on mastodon but it had much lower engagement https://x0f.org/@belcher/106093693514811764
09:36 < AaronvanW> luke-jr: what's your definition of "consensus"?
09:36 < AaronvanW> belcher: what's yours?
09:36 < luke-jr> AaronvanW: unanimity, or at least the absense of sustained objections
09:36 < belcher> consensus in development is when theres no substantial technical disagreement
09:37 < AaronvanW> luke-jr: at a particular time (past/present/future)? or simply always, across time?
09:37 < belcher> the word consensus is also used for a p2p network agreeing on the rules and history, but thats not what we mean here
09:37 < luke-jr> AaronvanW: depends on context
09:37 < AaronvanW> soft forks?
09:38 < luke-jr> AaronvanW: if I say "this has consensus", I mean now; if I say "this had consensus at the time", I mean then; etc
09:39 < AaronvanW> ok, and in your view BIP8 has consensus *now*?
09:39 < AaronvanW> (or not?)
09:40 < luke-jr> AaronvanW: dunno, BIP9 ST has thrown everything into chaos
09:40 < AaronvanW> did it have consensus in the past?
09:41 < luke-jr> yes, there were no objections at the first several activation meetings
09:41 < luke-jr> everyone agreed BIP9 was dead and BIP8 the way forward
09:41 < AaronvanW> ^ I can confirm this was the case, I was there, and re-read the logs this week
09:41 < luke-jr> and that was the general sentiment myself and many observerd for years prior
09:43 < AaronvanW> will BIP8 have consensus in the future? if this sounds like a silly question to ask, I agree, just exploring all options here.
09:43 -!- maybehuman [4ff5ed75@p4ff5ed75.dip0.t-ipconnect.de] has joined ##taproot-activation
09:43 < luke-jr> I can't predict the future
09:44 < luke-jr> (but note that consensus is not required, especially not on activation mechanism)
09:44 < AaronvanW> ok, thanks for clarifying.
09:44 < luke-jr> Segwit only achieved 80% support; BIP148 only 60% or so
09:44 < AaronvanW> belcher: when you say consensus, you pretty specifically mean in the present, I think?
09:44 < jonatack> belcher: didn't realize you were on the same mastodon instance, followed
09:44 < luke-jr> BIP8 with LOT=True for Taproot got to around 60% too, but that was before ST
09:45 < maybehuman> just one anecdote wrt bip8 had consensus: For me, I didn't bother to really look into it, and those who did seemed to agree on it, so yeah, bip9 seemed dead. It's only when the issues on the PRs popped up (doesn't work well on testnet) and so on, I startetd really thinking about how it works. I kind of suspect it was like that for more people
09:45 < luke-jr> hopefully when/if ST fails, BIP8(True) will get back to and exceed that 60%
09:46 < luke-jr> maybehuman: it works fine on testnet
09:46 < luke-jr> just not random infinite signets which nobody uses
09:46 < belcher> AaronvanW it can be at any time, but for something to be merged into core it would be nice if it had present consensus and likely-future consensus
09:46 < AaronvanW> belcher: do you think BIP8 had consensus at any point in the past?
09:47 < maybehuman> luke-jr: maybe so. The point is more that only when this came up I really startetd to think about whether or not block heights are a good idea. And I'm not really sure they are now
09:47 < belcher> maybe before we had any discussions about it... when the discussions happened then it became clear people didnt agree on the value of lot
09:48 < AaronvanW> belcher: if something has consensus and is merged in Core, but then an objection arises, should it be un-merged? what if it's already live on the network?
09:49 < belcher> yeah it should be unmerged.. if theres already been a release then thats a bad situation and it should be solved
09:49 < AaronvanW> eg. the 1MB block size limit
09:49 < belcher> how exactly it gets solved depends on the details, you cant just undo a code.. maybe you have to do another soft fork
09:50 < belcher> remember i said theres that other definition of the word consensus, where a p2p network agreeing on the rules and history, but thats not what we mean here... one way of putting it is "consensus means that those who agree cooperate, not that everyone must agree"
09:50 < belcher> for the 1mb situation people who disagreed made their own consensus around bcash or the other bcash forks
09:50 < AaronvanW> was there ever consensus for 1MB?
09:50 < belcher> idk ask satoshi :p
09:50 < luke-jr> yes
09:51 < luke-jr> 1 MB wasn't de facto relevant until May 2013
09:51 < luke-jr> with consensus
09:51 < belcher> most people showed up in bitcoin long after it was added, and through the block size debates most were convinced that it was a good thing (and though that didnt agree could always go to bcash)
09:51 < maybehuman> luke-jr: Or to put it in a different way: It showed that block height has this unspoken underlying assumption that one block equals roughly ten minutes. That wasn't so obvious to me before
09:51  * belcher bbl
09:51 < luke-jr> maybehuman: that's backward ☺
09:52 < luke-jr> maybehuman: using height is important because that expectation might not hold
09:52 < maybehuman> I don't follow
09:52 < luke-jr> maybehuman: if 1 block != 10 min, it's important to use heights
09:53 < maybehuman> because?
09:55 < maybehuman> I'm thinking more in terms of rollout, you need some kind of timeline usually. If "We have to be ready in x blocks" can mean two weeks or four, that sucks
09:55 < luke-jr> because otherwise the period count shifts and may even get cancelled; the general logic around the activation falls apart
09:56 < luke-jr> if you're ready in 2 weeks, 4 is fine
09:56 < maybehuman> yeah ok, that doesn't sound great, but what's the worst that could happen? It doesn't activate?
09:56 < AaronvanW> belcher: I think it's pretty clear that at some point, there wasn't consensus for 1MB, right? (just respond whenever you're back.)
09:56 < maybehuman> yes, if
09:56 < luke-jr> but if 4 puts you past the timeout, you lose the activation entirely
09:57 < maybehuman> luke-jr: No, I'm talking from the point of view of users
09:57 < luke-jr> maybehuman: BIP148 *had* to begin in August, because there was a risk miners wouldn't comply and it would timeout despite the mandatory signal
09:57 < luke-jr> users are the ones who care about activation..
09:57 < maybehuman> if I'm a vendor, Do I need to have my TR stuff ready by April 1 or April 15
09:58 < luke-jr> maybehuman: by Nov 12
09:58 < maybehuman> in a bip8 scenario?
09:58 < luke-jr> yes
09:58 < luke-jr> could be +/- a few days or whatever ofc, so round it down to "by November"
09:59 < maybehuman> ok, but you're still talking about signalling and such, not about when it actually becomes active?
09:59 < luke-jr> using MTP doesn't avoid that mind you
09:59 < luke-jr> no
09:59 < luke-jr> and vendors only care about when it's actually active
09:59 < luke-jr> vendors are not involved in signalling
09:59 < maybehuman> Yeah, signalling I don't care so much about I must say
10:00 < maybehuman> because if there's a problem with that, it just doesn't activate. So what
10:01 < maybehuman> and I agree that for mainnet it'll probably work out fine with bip8
10:02 < maybehuman> it's more a philosophical concern
10:02 < maybehuman> (and one for not-mainnets)
10:02 < luke-jr> "it doesn't activate" is a bug
10:03 < luke-jr> non-mainnets should be completely ignored for consensus rules
10:04 < maybehuman> ok, it's a bug, but not the end of the world
10:04 < luke-jr> …
10:04 < maybehuman> and stuff that doesn't work in dev environments tends to break more often
10:05 < maybehuman> at least in my experience
10:16 < wumpus> belcher: AaronvanW: yes i was pretty strongly in favor of BIP148, it was around the block size war and i was really tired of segwit being used as a negotiation pawn there, just wanted it to activate
10:18 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
10:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
10:37 -!- maybehuman [4ff5ed75@p4ff5ed75.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
10:50 < harding> I didn't support BIP148, although I would've supported BIP149.  https://twitter.com/hrdng/status/869360246501847042
11:04 -!- Netsplit *.net <-> *.split quits: luke-jr, justinmoon_, CubicEarth, shesek, proofofkeags, da2ce7, copumpkin
11:07 -!- Netsplit over, joins: proofofkeags, shesek, luke-jr, justinmoon_, CubicEarth, copumpkin, da2ce7
11:15 < AaronvanW> I supported BIP148 futures markets ;) https://twitter.com/AaronvanW/status/870006887973912577
11:17 < AaronvanW> (that were unfortunately never established-- only later for 2X... I think we'd all have learned way clearer lessons from BIP148 had they existed.)
11:34 < harding> AaronvanW: I'm not sure it would've made it clearer, I think you'd still have people claiming (as I do) that multiple parallel attempts to activate makes it unclear exactly which of those efforts was essential to activation, which was non-essential, and which retarded activation.
11:56 < AaronvanW> harding: it would have made clear how much economic weight was actually behind BIP148, right? (making clear whether it was actually a bluff or not, or to what extent.)
11:57 < AaronvanW> btw earlier today I defined "user" basically as equivalent to "holder". I think a better definition might actually be "those who pay miners". Miners are paid by holders through inflation, but also by transactors through transaction fees.
11:57 < AaronvanW> cc aj ^
12:00 < AaronvanW> miners = those who produce valid blocks. users = those who pay them, and therefore also decide what are valid blocks.
12:00 < AaronvanW> (valid = what they're willing to pay for)
12:02 < belcher> what is the purpose of correctly defining all these words?
12:02 < belcher> i suppose you're trying to figure out who has the legitimacy in defining which soft fork activation to do?
12:05 < AaronvanW> I'm not sure "legitimacy" is even the best word. I guess my answer would be, if you're trying to figure out who defines Bitcoin, or who the protocol should be optimized for, my answer would be "users", and by defining it properly, you understand why I mean by that.
12:05 < AaronvanW> *what I mean by that
12:06 < belcher> also i guess if you define "users" then that tells you who has power in a "user activated soft fork"
12:06 < AaronvanW> yes
12:07 < belcher> the entities which have power in a UASF are those who use full node wallets to accept bitcoin as payment for things, because they have the power to say "sorry your money is no good here"
12:07 < belcher> "users" cant be the people paying miner fees, because if theres a chain split one transaction can be valid on both chains
12:11 < AaronvanW> yes but they don't (necessarily) have the same value on both chains, which derives from fee pressure. If they are paying on both chains, they're paying on both chains though.
12:11 < belcher> and where does that value come from? it comes from there being an economy ready to accept that coin as payment
12:12 < AaronvanW> But I should remove the "define" from the definition; what is "Bitcoin" is ultimately an (inter)subjective thing.
12:12 < AaronvanW> From my answer, rather.
12:13 < harding> AaronvanW: re: "made clear how much economic weight [...] behind BIP148", I think the market would've been either "segwit activates by x date" or "segwit hasn't activated by x date", right?  In which case, a bet on activation is a bet on activation by any mechanism, not just BIP148, so it doesn't eliminate the conflation.
12:13 < AaronvanW> the value from the coin itself comes from the demand to hold.
12:14 < belcher> be careful not to confuse value with price
12:14 < harding> AaronvanW: (we can continue market discussion after you finish the terms argument with belcher.)
12:14 < AaronvanW> harding: "I think the market would've been [...]" <--- no
12:14 < belcher> the price comes from how many people hold it, the value comes from the properties it has for example being able to send it anywhere in the world over the internet without censorship
12:14 < AaronvanW> harding: I will :)
12:15 < harding> AaronvanW: ok, interested to hear how the market would work.  (when you're ready)
12:15 < belcher> hmm maybe a more useful way to put it is that the economy with full nodes defines the rules (and they might not be valuable rules but for bitcoin they are)
12:15 < AaronvanW> belcher: no these are usecases. and price is measured in something else, USD. value derives from demand to hold.
12:15 < AaronvanW> (eg. USD)
12:17 < AaronvanW> harding: Paul Storz is more of an expert when it comes to implementation details than I am, maybe take a look at this blog first -> https://www.truthcoin.info/blog/fork-futures/
12:19 < AaronvanW> belcher: I think full nodes just make sure that you're holding what you want to be holding.
12:20 < AaronvanW> (you most obviously do this when you just start holding, that is, when you accept btc in exchange.)
12:22 < AaronvanW> Oh interesting opening line in Paul Storz' blog. "Some things are not disputed: 1) That Bitcoin Miners, and Bitcoin Developers, both serve the users." <-- this is why I was so surprised earlier today, AFAIK that part wasn't disputed.
12:23 < harding> AaronvanW: quickly skimming Sztorc's article, I don't see how it materially differs from my proposed implementation.  You still only have "segwit activated" and "segwit not activated" outcomes; his thing just uses options for that rather than futures.
12:23 < belcher> well as we've found out the word "user" is defined differently
12:25 < harding> I don't know how you measure "segwit activated by BIP148"; presumably, if that was measurable, we'd not be debating it now :-)
12:26 < luke-jr> 1) BIP 9 very clearly failed
12:26 < luke-jr> 2) BIP148 was enforced as defined
12:26 < luke-jr> 3) 2X (attempting to claim credit via BIP 91) was not successful
12:26 < belcher> i wouldnt say bip9, more like any possible MASF
12:27 < belcher> if segwit was being activated with IsSuperMajority or bip8 lot=false then it wouldve run into the same problems
12:29 < AaronvanW> harding: so I think you would have to think in terms of three different "future coins". 1) "BIP148 coin", 2) "Legacy BTC" <-- these two would come to exist if a split were to take place, and 3) "Segwit BTC" <--- this one would exist if miners activated Segwit. I'm just spitballing names obviously.
12:30 < AaronvanW> And then the idea would somehow be that BIP148 bettor get paid either BIP148 coin (in case of split) OR Segwit BTC (in case of no split).
12:30 < AaronvanW> I think that's the way it would make sense. But I'm also thinking out loud a bit.
12:32 < luke-jr> belcher: sure, I'm just saying it's pretty clear BIP148 activated Segwit there
12:32 < luke-jr> the facts don't really admit any other reasonable interpretation
12:33 < harding> I don't agree that BIP9 very clearly failed.  Just because there were a moderate number of people willing to do BIP148, doesn't mean that alone was what motivated miners.  There was a lot of drama and noise, and it seemed clear to me that even if segwit didn't activate before the BIP9 time out, there would've been broad support for some sort of flag day activation afterwards.  Moreover, it's possible that many miners wanted to signal for
12:33 < harding> BIP141 but Bitmain had some sort of hold over them, which was broken by the covert asicboost revelations and by Bitmain deciding to do its "UAHF" thing.  And those are just a few of the conflationary factors.  Speaking only for myself, I think if miners had truly been opposed to BIP141, I don't think the BIP148 movement had enough economic weight at the time to have forced them to signal.
12:34 < faketoshi> bip9 + an alt client running bip8
12:34 < faketoshi> you need both, and we have both again :D
12:35 < faketoshi> unfortunately "fail fast" might make things more difficult
12:36 < luke-jr> BIP 9 is not needed or of any value
12:38 < harding> Hmm, I guess my last sentence above is a bit of a tautology.  Sorry.  I mean to say, I don't think the BIP148 movement was strong enough to have put significant economic pressure on miners.  If BIP148 had been backed by exchanges, or at least had large number of exchange customers saying that they would withdraw from exchanges before any chainsplit, then I think it might have had enough economic weight.
12:39 < AaronvanW> harding: I don't think any of that would affect the futures markets, if that's what you're responding to. I'm sorry I can't explain it more clearly. It's one of these things where I "know" it would work, but if I'd had to explain it I'd need to take more time to think about it. (Like, some bettor would need to get a refund if a split does/doesn't happen, others not.) We're basically talking prediction markets.
12:39 < belcher> harding maybe it didnt have enough weight but nonetheless scared bitmain into activating
12:40 < harding> AaronvanW: oh, sorry, didn't see you previosu respnose.  Having a bip148 coin in the case of a split does kind of make sense.  I'll have to think about that.
12:41 < AaronvanW> FWIW I was discussing this with BlueMatt the other day, and he strongly agreed with me about futures markets, but also said something along the lines of, can't tell you on the spot HOW they would work exactly, but pretty sure they should work.
12:41 < harding> belcher: sure, but how do you disentangle that from other things that may have scared bitmain into activating?  E.g., the idea of a follow up flag day activation, or people seriously considering a PoW change, or just more stupid meetings?
12:42 < belcher> harding iv collected up some links here which _might_ convince (though i admit we can never know 100% for sure) https://gist.github.com/chris-belcher/a8155df5051bb3e3aa96#the-uasf-caused-segwit-activation
12:42 < belcher> this is strong evidence that they were thinking about UASF and bip148 rather than a follow up flag day or pow change https://twitter.com/chris_belcher_/status/905231603991007232
12:42 < harding> AaronvanW: I think future markets can be useful, but I'm not sure they can tell you what caused what.  It's that classic problem with market news reporting: my newspaper says "market dropped 5% on Biden proposing higher capital gain taxes", but do they really know that?  Nope, they're jsut guessing.
12:44 < AaronvanW> harding: that sounds wrong to me. futures markets predict what the market expects will happen in the case of various future events. IF Biden is elected, the stock market will go up. IF Trump is elected, the stock market will go down. For example.
12:44 < harding> belcher: just skimmed that.  I'm not sure there's anything there that I don't remember in essence.
12:45 < AaronvanW> harding: sorry, I meant prediction markets
12:45 < AaronvanW> not futures markets
12:46 < AaronvanW> prediction markets are explicitly about what will cause what.
12:46 < AaronvanW> (or what the market expects about what will cause what, rather.)
12:47 < harding> AaronvanW: sure, "if biden is elected, stock market goes up" tells you that B followed A (correlation) but it doesn't tell you that A causde B (causation).
12:48 < AaronvanW> harding: it does if it shows you a different result for Trump, don't you think?
12:50 < harding> AaronvanW: I guess if you do the whole matrix [(biden, market up), (biden, market down), (trump, market up), (trump, market down)], maybe it does.
12:50 < AaronvanW> btw as for BIP148, I do think it's pretty clear that BIP148 got segwit activated. what's not clear is how many users would have *actually* forked off and continue on a BIP148 coin if it had had to come to it.
12:51 < AaronvanW> harding: exactly :)
12:53 < luke-jr> AaronvanW: harding: not necessarily - it could be that the reaction is delayed 4 years or whatever
12:53 < luke-jr> sample size is too small ;)
12:54 < AaronvanW> luke-jr: well yeah you'd have to define the market on a specific date in the future
12:54 < harding> AaronvanW: if people wouldn't have followed through with BIP148 enforcement, then it wasn't BIP148 that activated segwit but the threat of it that activated segwit.  That seems like an important distinction, as you're risking economy-wide disruption on a bluff.
12:54 < harding> luke-jr: agree with AaronvanW; futures and options always have expiration dates for that reason.
12:54 < AaronvanW> harding: what disruption, exactly? (if it was a bluff.)
12:55 < harding> AaronvanW: the people who weren't bluffing being forked off the network.
12:55 < AaronvanW> oh I thought you meant if no one would have gone
12:56 < harding> AaronvanW: if no one enforces a UASF, then, yeah, there's no economic disruption, just a bunch of people benig revealed as bluffers.
12:59 < luke-jr> UASFs only work if there's economically significant enforcement; just like any protocol rule
13:02 < harding> Right, and I'm highly doubtful BIP148 had economically significant enforcement.
13:05 < AaronvanW> harding: you bring up a very interesting point. I think the divide in the BIP148 camp in context of LOT=true may in part be between the bluffers and those who meant it? probably simplifying a bit.
13:06 < luke-jr> harding: exchanges aren't the economy
13:07 < luke-jr> exchanges are simply a service used by the economy
13:07 < luke-jr> if they don't do what the economy wants, people will just use other exhcnages
13:09 < harding> belcher: looking at your gist, I'm not sure about the statement '[Luke's poll] results show that over 60% of people agreed with "I unconditionally support BIP148"'.  The actually question is about "unconditional support" and it looks to me like only ~40% said "strongly agree".  The others said "agree" only; I'm not sure what (weaker) agreement means in the context of "unconditional support".
13:09 < harding> harding: I never said exchanges were the economy.
13:10 < harding> " or at least had large number of exchange customers saying that they would withdraw from exchanges before any chainsplit"
13:17 < luke-jr> the timeframe for BIP8 (18 months) is intended to be such that the economic majority have upgraded to it by November, and almost everyone by 2022 Nov
13:36 < AaronvanW> BIP148 poll: https://twitter.com/AaronvanW/status/1388230740513599490
13:39 < harding> AaronvanW: I'll be interested to see the results.
13:40 < harding> luke-jr: I agree that an 18 month timeframe is enough to allow for upgrading, but no amount of time is enough to ensure upgrading.
13:46 < luke-jr> harding: at some point, people who don't are responsible for their own negligence (in the context of an upgrade like Taproot w/ consensus)
13:46 < luke-jr> back in Feb meetings, there seemed to be a general sense that 12mo was enough for that; 18 is extra safe
13:46 < harding> luke-jr: it's negligent to upgrade to a UASF unless you know it's going to be economically enforced.
13:47 < harding> s/know/believe/
13:47 < luke-jr> harding: it's a reasonable expectation
13:48 < harding> luke-jr: I'm not sure it is just because a few people release a UASF client.  I think you need broader and stronger evidence of support.
13:48 < jeremyrubin> 130 blocks till signalling starts! everyone get out of IRC and go have a margarita or something
13:48 < luke-jr> AaronvanW: I'm not sure supporting BIP148 for real implies selling anti-Segwit coins necessarily
13:48 < luke-jr> harding: 60% supported LOT=True, and even more said they would switch to the UASF client
13:48 < AaronvanW> luke-jr: how would you define it?
13:49 < luke-jr> AaronvanW: enforcing it on received payments
13:49 < AaronvanW> what is "supporting for real"
13:49 < AaronvanW> yeah fair
13:50 < harding> luke-jr: 60% of people who responded to your poll, which I personally doubt is representative of the economy at large.
13:50 < AaronvanW> I think I'll let it roll regardless, instead of making a new poll
13:51 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
13:52 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation
14:13 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds]
14:42 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
15:18 < AaronvanW> belcher: I think one of the reasons I wanted to cleanly define "users" (those who pay miners), is because it then becomes clear that LOT=false is not an act of aggression. Rather, it's like you have (say) a personal chef, who you're paying a fair price, and you tell him: "Dear chef, starting next month, I'm going to become a vegetarian. Please only make me vegetarian food." Surely that's not an act of aggression, that
15:18 < AaronvanW> 's what you're paying him for.
15:19 < AaronvanW> *LOT=true
15:19 < belcher> i see, so you were concerned about it appearing as antagonistic towards miners
15:19 < AaronvanW> *because it then becomes clear that LOT=true is not an act of aggression
15:19 < AaronvanW> belcher: aj was, in particular
15:20 < AaronvanW> (somewhere upthread)
16:33 <@aj> AaronvanW: suppose you go to a restaurant, and tell the chef, "hey, i'm going to get you fired unless you only cook vegan meals from now on. you can do it voluntarily if you like, but if you don't do it by X i'll organise a boycott and you'll be out of a job" comes across as aggressive, especially if everyone else is saying "hey, there's no need for talks of a boycott, let's see how the vegetarian
16:33 <@aj> thing goes first"
16:34 < AaronvanW> no what you say is: "Hi, I'd like vegetarian food, do you have any? No, ok, thanks I'll find another restaurant."
16:35 < belcher> right so the argument is that UASFs are a boycott
16:35 < belcher> i never thought of it that way
16:35 < AaronvanW> Or the chef says: "Sure, that will cost 10$." "Ok great here you gp."
16:35 <@aj> AaronvanW: in a multichain world where splitting has no costs, sure; that's not the pow/bitcoin world
16:36 < AaronvanW> boycott isn't aggression either. it's voluntary, free market.
16:37 < belcher> i suppose now we need to get into the ethics of boycotts if we want to figure out whether they are antagonistic (fwiw i think they are antagonistic if only because they require the miner operator to do extra stuff, but it was worth it in the segwit case and not worth it for taproot given what we know right now)
16:37 < AaronvanW> aj: so? sometimes companies make investments in things the market has no interest for, or stop having interest in. are they obligated to buy their stuff anyways?
16:37 < belcher> steelmanning the pro-lot-true side, they could say yes its antagonistic but so what?
16:39 < AaronvanW> aj: in this case the miners are perfectly capable to produce what users want anyways.
16:40 < AaronvanW> asking someone to do stuff for you in return for payment isn't antagonistic belcher?
16:40 < AaronvanW> that's free market.
16:40 < AaronvanW> miners are free to refuse. they won't get paid.
16:40 < AaronvanW> that's all.
16:41 <@aj> AaronvanW: is a 51% attack aggressive or antagonistic? it's a free market, so if you have 51% of the hashpower isn't it your right to choose what blocks you mine on top of?
16:41 < AaronvanW> aj: yes miners can choose what to do with their own hardware. users are free to change PoW in response.
16:42 <@aj> AaronvanW: the phrase you're looking for is "no, i don't think a 51% attack is aggressive or antagonistic"
16:44 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
16:44 <@aj> AaronvanW: which is the same logic libertarians use to say "it doesn't matter if twitter and google and facebook attack free speech" so you're not alone, but i don't agree
16:44 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
16:45 < belcher> iv kind of had my mind blown in realizing that a UASF especially something like bip148 is a boycott, it even has the big social movement like real life boycotts have
16:46 < belcher> thats why theres all the hats and the memes and retweets, because boycotts work best when everyone takes part at the same time
16:48 < harding> belcher: here's me replying to journalists in 2017 about UASF being a boycott: https://gist.github.com/harding/1ce496734412f188639f4663fde8cf8a  "A UASF is a boycott on steroids."
16:48 < AaronvanW> Yeah a 51%-attack to eg. steal coins is an attack. I think eg. Voskuil takes the more libertarian position on something like this. (But IIRC "veteran Core devs" generally do not.)
16:49 < AaronvanW> 51%-attack is also described in the white paper IIRC, in the sense of "dishonest".
16:49 < belcher> in either case i think we can all agree that a 51% attack is something we want to avoid because it reduces bitcoin's features
16:49 < AaronvanW> "honest miners" / "dishonest miners"
16:49 < belcher> harding nice
16:49 <@aj> AaronvanW: "honest" peers extend the most-work valid chain, a 51% attack doesn't. that's just the definition of "honest" in terms of pow security
16:50 < AaronvanW> aj yes and stealing is also unethical.
16:51 < AaronvanW> "A boycott is an act of nonviolent, voluntary and intentional abstention from using, buying, or dealing with a person, organization, or country" <--- not the case here, the same miners can produce the signaling blocks.
16:52 <@aj> AaronvanW: bitcoin needs to work in an environment where unethical people have hashpower, or it's a failure. if your scheme fails when you replace "honest" with a different word that doesn't have moral overtones, it fails in real life too
16:52 <@aj> "the same consumers can purchase from the store they're boycotting"
16:52 < belcher> AaronvanW that works if you say the organizations are "any miners not signalling"
16:52 <@aj> "the store can comply with the boycotters demands"
16:52 < AaronvanW> aj: that's *why* we have a PoW change as a nucear option, for example. and UASFs.
16:53 < belcher> PoW changes wont work IMO
16:53 < belcher> whats the stop the new PoW being vulnerable to the same problems as the last one?
16:53 < jeremyrubin> aj: in theory the best way to UASF is to burn your coins on the chain you're boycotting and not on the other chain
16:54 <@aj> AaronvanW: if your system is failing with sha256d it'll likely fail with aaronvanwhash too
16:54 < belcher> if anything the last PoW change means becoming a miner a more risky, more risk = more cost, so we just add a cost to mining which might have an effect of pricing out smaller miners and therefore harming decentralization
16:54 < AaronvanW> belcher: it's better than giving up.
16:54 < belcher> i note that bitmain produced ASICs for many different PoW algorithms
16:54 <@aj> jeremyrubin: better to sell your coins on the chain you're boycotting and make a profit, cf BCH/BTC
16:54 < belcher> AaronvanW isnt that like saying "sure fighting the enemy tanks with our bows and arrows wont work, but its better than giving up"
16:55 < AaronvanW> jeremyrubin: the best way is to *sell* the coins on the other chain.
16:55 < belcher> yeah it is better, we'll still lose wont we?
16:55 < AaronvanW> belcher: maybe miners will learn a lesson? we'd at least win some time, presumably.
16:56 < belcher> they'd learn a lesson that mining is more risky than they previously thought
16:56 < roasbeef> there're literally millions of bitcoin users world wide, polls w/ 300 participants literally mean nothing, ppl really seem to overesimate the number of "activist users" that exist, most users just care about the basic tenants of the system and anything else is just a bonus
16:56 < jeremyrubin> One can argue it's unethical to sell; plus with creative burning you can cause ample MeV issues
16:56 < belcher> remember a PoW change hurts the good miners equally with the bad miners
16:56 < molz_> it'd be harder to change pow on bitcoin than on an altcoin
16:57 < roasbeef> the whole point of softforks is that you're able to update the system w/o needing to poll or have direct approval of all users, sampling them all isn't feasible, so all you have is price at the end of the day if some fissure was actually to happen
16:58 < AaronvanW> jeremyrubin: it's unethical to sell what I own?
16:58 < belcher> i dont see how burning hurts the coin you dont like, doesnt burning make its exchange rate go up because it has a lower supply?
16:59 < AaronvanW> belcher: that's why it's called the nuclear option. desperate times call for desperate measures.
16:59 < jeremyrubin> belcher: you can "burn" by releasing as an anyonecanclaim output
16:59 < belcher> AaronvanW my point is nuclear weapons actually work, maybe a better name is "toy slingshot option"
17:00 < jeremyrubin> AaronvanW: I think so, in certain circumstances, yes. For example it's unethical to sell the bullets out of the gun you have pointed at someone to that someone
17:00 < belcher> or maybe "last stand option"
17:01 < jeremyrubin> maybe ethical is the wrong word, probably mean moral
17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:03 < AaronvanW> jeremyrubin: that has absolutely nothing to do with what we're talking about
17:04 < jeremyrubin> I think that the way I would term it is create chaos, driving *all* prices down, confusing noobs into buying your side, using the profits to reinvest into the "right" side. I consider that immoral. By definition of the certainty you have, the buyer is an idiot you are taking advantage of
17:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
17:05 < jeremyrubin> it's sorta a "lemon law" scenario
17:06 < AaronvanW> aj "the same consumers can purchase from the store they're boycotting" <-- I'm missing your point, I think?
17:07 <@aj> "the same miners can produce the signaling blocks." / "the store can comply with the boycotters demands"
17:08 -!- belcher_ is now known as belcher
17:08 < AaronvanW> the store can offer the services that the market wants
17:08 < AaronvanW> that's what stores do
17:08 < molz_> "the same boycotters beg the miners they boycott.. "please mine my txs"" Lol
17:08 < AaronvanW> miners mine blocks that users do. that's what miners do.
17:08 <@aj> AaronvanW: there's no need for boycott in that scenario
17:09 < AaronvanW> you're the one using the term boycott, not me.
17:10 < AaronvanW> users don't care which miners mine the blocks.
17:10 < AaronvanW> miners can even do it anonymously.
17:11 <@aj> AaronvanW: lot=true is a boycott; you can influence what stores sell and what miners mine without those
17:11 < AaronvanW> consumers influence what stores sell.
17:11 < AaronvanW> that's how markets work.
17:11 < belcher> looking at the big picture, so what if its a boycott? boycotts have achieved some good things
17:12 < jeremyrubin> users do care which miners mine btw
17:12 <@aj> AaronvanW: for taproot; "hi we want secure taproot transactions!" 60% of miners: "okay, sure, we'll take your fees" 40% of miners: "nah, our traditional tx business has been fine, we'll reconsider in a decade after blockchain.com implements them"
17:12 < AaronvanW> right, there's nothing unethical about boycotts in the first place. but this isn't even a boycott.
17:12 < jeremyrubin> if it's 80% bitmain, users do care
17:12 < belcher> mining is anonymous so if it comes to it users cant discriminate based on a miner's identity
17:12 < jeremyrubin> they might not be able to *tell*, but it's wrong to say they are vendor agnostic
17:12 <@aj> AaronvanW: lot=true: "okay, we're going to boycott your store for a week"; flag day: "okay, sure, but hey 40%ers: be prepared for a drop-off in custom"
17:13 < belcher> right now pools put a message in the coinbase scriptsig but they could not do that, or just lie
17:13 <@aj> s/week/fortnight/
17:13 < jeremyrubin> belcher: pools could sign blocks if they wanted to
17:13 < belcher> i doubt the economy will want to encourage that, thats basically miner pool whitelisting
17:13 <@aj> AaronvanW: "this isn't even a boycott" -- if we can't agree on terminology, there's no point talking
17:13 < belcher> therefore the death of decentralization
17:13 < AaronvanW> jeremy: no, they don't. users accepted bitmain blocks just fine.
17:14 < jeremyrubin> no?
17:14 < AaronvanW> yes
17:14 < jeremyrubin> literally there was a boycott which saw segwit pushed through to fuck over bitmain
17:14 < AaronvanW> no, bitmain blocks that signaled were accepted as valid.
17:14 < AaronvanW> like all blocks.
17:14 < jeremyrubin> it had the impact of reducing the value of their hardware
17:15 < jeremyrubin> a boycott is not absolute
17:15 <@aj> jeremyrubin: bitmain always had the option of mining covert asicboost blocks that didn't include segwit transactions
17:15 < jeremyrubin> sure, but the long term economics of that are poor
17:15 < jeremyrubin> in any case it's still the case that there was also a movement to block asicboost entirely
17:15 < jeremyrubin> due to the patent encumberance
17:16 < AaronvanW> aj: I don't agree it's a boycott, and I've explained why, and I'm continuing to explain why.
17:16 < jeremyrubin> so i think that it's relatively safe to say that people do care somewhat where the blocks come from because we care that blocks come from decentralized (this is my only point) sources
17:16 < belcher> AaronvanW where did you explain why, sorry i mustve missed it
17:16 < jeremyrubin> maybe we can't tell if it is decentralized or not
17:16 < jeremyrubin> but we also can't tell if a burger is organic
17:16 <@aj> 06:48 <jeremyrubin> 130 blocks till signalling starts! everyone get out of IRC and go have a margarita or something
17:17 < jeremyrubin> heh
17:17 <@aj> jeremyrubin: and i'm like "damn, it's 7am"
17:17 < jeremyrubin> aj: i'm only here because I was working on taxes and wanted something less frustrating
17:17 < jeremyrubin> pizza and beer inbound at 7pm
17:18 < AaronvanW> belcher: it's not against a specific business.
17:18 < belcher> boycotts dont have to be against specific businesses
17:19 < AaronvanW> "withdraw from commercial or social relations with (a country, organization, or person) as a punishment or protest."
17:19 < belcher> that fits here
17:19 < AaronvanW> no it doesn't.
17:19 < belcher> some examples https://en.wikipedia.org/wiki/Boycott#Notable_boycotts "the Arab League boycott of Israel and companies trading with Israel."... that was against all businesses trading with israel, if a business stopped trading with israel then it would no longer be boycotted
17:19 < AaronvanW> any miner is free to mine valid blocks.
17:20 < AaronvanW> there's no boycott against a specific miner.
17:20 < belcher> a business in my example is free to not trade with israel
17:20 < belcher> (i dont mean to get into any politics about israel its just an example)
17:20 < AaronvanW> you're confirming my point.
17:20 < AaronvanW> not sure if you realize that?
17:21 < belcher> yep i still disagree
17:21 < belcher> say you're some french company, you sell shoes to israel, you get boycotted, you stop selling shoes to israel, the boycott stops... you didnt have to change your name or anything else just change one of your actions (selling shoes in this case, signalling in blocks in the UASF case)
17:22 < belcher> and the terms of the boycott dont mention your french name, instead it says "any country or company trading with israel"
17:23 < jeremyrubin> AaronvanW: I think that the definition you're using is over pedantic on the WHO as opposed to the WHAT or WHY variables
17:23 < AaronvanW> Which UASFer has ever cared who his miner was, or what his miner did? All they ever cared about was that the blocks were valid.
17:24 < belcher> AaronvanW in the same way, the arab league boycott didnt care about the company's name or what they did, it only cared whether it traded with israel
17:24 < jeremyrubin> you can quantify a boycott however you like
17:25 < jeremyrubin> WHO = anyone who X
17:26 < AaronvanW> are vegetarians boycotting meat?
17:27 < belcher> i suppose so yes
17:27 < AaronvanW> and there's something wrong with that?
17:27 < belcher> you mean ethically/morally? not really
17:27 < jeremyrubin> That's a good example; because vegetarians particularly do want to harm the meat industry as well
17:27 <@aj> "many" vegetarians maybe
17:28 < jeremyrubin> aj: sure
17:28 < belcher> that Notable boycotts wikipedia page has a few examples that most people agree are good things
17:28 < AaronvanW> ok great. so you guys call it a boycoot, I call it a market, we all agree it's perfectly fine to do.
17:28 < belcher> yeah thats back to the point of "ok its a boycott, so what?"
17:28 < jeremyrubin> also where you cite the wiki, later in that para
17:28 < jeremyrubin> "Sometimes, a boycott can be a form of consumer activism, sometimes called moral purchasing. When a similar practice is legislated by a national government, it is known as a sanction. "
17:29 < jeremyrubin> so if you want to call UASF moral purchasing to be more specific that's ok
17:29 < jeremyrubin> "we'll only accept coins from block producers who do X practice"
17:30 < AaronvanW> we'll only accept valid blocks.
17:31 < jeremyrubin> Yes, But you changed that definition quite recently
17:31 < belcher> i think stronger arguments against lot=true are 1) against any UASF before we've tried a MASF because of the risk 2) forced signalling at the end of the bip8 period 3) opens up the possibility and risk of a bip148-style social movement which does forced signalling at another time
17:31 < belcher> the boycott thing is true but you could just say so what if its a boycott
17:32 < jeremyrubin> so I don't think "valid" has any useful definition if that's how it's going to be read... sure, the boycott is "only accept valid blocks" and "change your rules so that valid means valid - X thing"
17:32 < AaronvanW> I'm logging off guys.
17:32 < belcher> goodnight!
17:32 < AaronvanW> cheers
17:33 < jeremyrubin> do you count sheep or signalling blocks to fall asleep these days
17:33 < AaronvanW> I'm an aphantast.
17:34 < jeremyrubin> good, blocks are just bytestreams
17:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:39 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 260 seconds]
18:31 < luke-jr> nah, blocks are abstract. the bytestreams are just how you choose to serialise them (for now)
18:56 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Quit: Hmmm]
19:20 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
20:06 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has joined ##taproot-activation
20:20 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
21:00 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye]
21:00 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-activation
21:28 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 268 seconds]
21:37 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Quit: Leaving]
21:51 -!- CryptoSiD [SiD@CryptoSiD.DonSiD.net] has quit [Quit: .]
21:52 -!- CARO [~Cesar@2804:7f4:c29d:a959:9424:92ed:d61d:da7f] has joined ##taproot-activation
21:54 -!- CARO1 [~Cesar@2804:7f4:c1a0:f570:9424:92ed:d61d:da7f] has quit [Ping timeout: 260 seconds]
22:04 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
22:04 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
22:05 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
22:05 -!- BB-Martino_ [~martino@bitbargain.co.uk] has joined ##taproot-activation
22:08 -!- huesal_ [~root@152.170.89.151] has joined ##taproot-activation
22:13 -!- Netsplit *.net <-> *.split quits: andytoshi, BB-Martino, Emcy_, jnewbery, jrawsthorne, huesal, jeremyrubin
22:18 -!- commmon [~common@unaffiliated/common] has quit [Remote host closed the connection]
22:20 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
22:24 -!- Netsplit over, joins: jnewbery, andytoshi, jrawsthorne
22:29 -!- CryptoSiD [SiD@CryptoSiD.DonSiD.net] has joined ##taproot-activation
22:47 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
22:51 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
23:38 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation
23:40 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Read error: Connection reset by peer]
23:57 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds]
--- Log closed Sat May 01 00:00:42 2021