gistfile1.txt

@jeremy I am somewhat perplexed that you think the UASF chain could be wiped out :confused:

Jeremy Rubin  10:28 AM
Can you give me a rigorous definition of "wiped out"

merkle syrup  10:28 AM
Non UASF chain has more HR, longer chain, UASF nodes drop their softfork chain and switch over to “core” chain.

Jeremy Rubin  10:28 AM
because w/o such it's hard to discuss as when I tried previously issues I raised were not a part of being "wiped out"

merkle syrup  10:28 AM
Despite it violating their rules

Jeremy Rubin  10:30 AM
gotcha, switching to a nonsignalling core chain cannot happen without a hard fork of clients running UASF i think

merkle syrup  10:31 AM
Yes

Jeremy Rubin  10:31 AM
but I think that's like saying "a wipeout is when you fall off on the left side of the surfboard, why would you fall to the right?"

merkle syrup  10:31 AM
Uh
10:31
No

Jeremy Rubin  10:32 AM
you've defined a wipeout to be the impossible case definitionally, but excluded other ways the chain is disfunctional

merkle syrup  10:32 AM
This is entirely about the asymmetric risk. The “core” chain always runs a risk of wipeout because there is a SF chain that violates none of its rules that may someday exceed your chain.
10:32
The UASF chain does not have to fear this, even if only 1% of the HR.

Aaron van Wirdum  10:32 AM
Core chain -> longest
UASF chain -> shorter
^ both exist
...time passes...
UASF chain -> longer
Core chain -> shorter? Nope! Core nodes switch to UASF chain, so the Core chain is "wiped out".
10:32
^ only one exists

merkle syrup  10:33 AM
This is entirely why UASF can be an intolerant minority that the hashers can’t ignore.

Jeremy Rubin  10:33 AM
why would a more work chain abandon and reorg itself?

merkle syrup  10:33 AM
Because it needs to stay longer forever

Jeremy Rubin  10:33 AM
Isn't that definitionally a 51% attack?

merkle syrup  10:34 AM
Core would have to HF and deliberately reject the UASF chain.

Jeremy Rubin  10:34 AM
why would these miners reorg their own block rewards?

1 reply
Today at 10:36 AMView thread

merkle syrup  10:34 AM
Because the UASF chain doesn’t violate any rules on the core chain.

Aaron van Wirdum  10:34 AM
The difference is that 51%-attacks require miners to mine against their direct incentives in hope of getting a larger gain by double spending.
Switching from "Core chain" to "UASF chain" can perfectly align with direct incentives, if the UASF chain is/becomes more valuable.

merkle syrup  10:35 AM
This is basic backward compatibility. Inaction leads to inadvertent acceptance of UASF rules.

Jeremy Rubin  10:35 AM
This is not truewe
10:35
inaction leads to non activation of taproot
10:36
people do need to upgrade software to signal

merkle syrup  10:36 AM
Not if there’s a UASF client.

Jeremy Rubin  10:36 AM
yes, it leads to no valid blocks being found
10:36
for UASF clients

merkle syrup  10:36 AM
If 0% yes
10:36
Anything greater and the risk can’t be ignored

Jeremy Rubin  10:36 AM
so you clearly need to define some level of "action"

merkle syrup  10:36 AM
0%

Aaron van Wirdum  10:36 AM
replied to a thread:
why would these miners reorg their own block rewards?
A better question IMO is: why would miners mine on a chain that can be wiped out in the first place?

merkle syrup  10:37 AM
Miners demonstrably won’t do this - hence BIP91
10:37
We have evidence.

Jeremy Rubin  10:37 AM
what evidence?

merkle syrup  10:37 AM
Miners would have to risk so much to deny an upgrade which they all apparently want - i.e not going to happen
10:37
BIP91

Jeremy Rubin  10:38 AM
how is a document evidence?
10:38
There were like 5 BIPs

merkle syrup  10:38 AM
Ok usage of BIP91 then?

Jeremy Rubin  10:38 AM
who used it?

merkle syrup  10:38 AM
Miners

Jeremy Rubin  10:38 AM
how many and which ones
10:38
how do you know that's the code they ran?

merkle syrup  10:38 AM
wut

Aaron van Wirdum  10:39 AM
They signaled for it, IIRC. And then they all did what BIP91 did. (edited) 
10:39
https://bitcoinmagazine.com/technical/bip-91-has-activated-heres-what-means-and-what-it-does-not

merkle syrup  10:39 AM
If this is a concern ST doesn’t help.
10:40
Fake signalling etc
10:40
Did you read Luke’s reddit post in the early days of BIp148?
10:40
When he explained that above a certain, hard to define but small % of users running UASF, it becomes more risky not to switch to UASF.
10:41
It becomes as existential risk for those ignoring the SF

Jeremy Rubin  10:41 AM
Again, you're treating behavior as fully endogenous to the system
10:41
this is a big risk, because behavior is a fully exogenous thing

Aaron van Wirdum  10:41 AM
"Miners have been signaling support for BIP 91 over the past couple of days through another piece of data, “bit 4.” Once 269 blocks within a 336-block window included bit 4, this BIP 91 soft fork locks in. This threshold was just met."
(From my article.)

merkle syrup  10:41 AM
That was a happy day
10:42
And an interesting face-saving mechanism
10:42
So much posturing :joy:

Jeremy Rubin  10:42 AM
That little signalling means almost nothing
10:42
Perhaps the timeline was too fast for people to e.g. switch poools

Aaron van Wirdum  10:42 AM
Miners 1) signaled for BIP91, and 2) did what BIP91 did. (edited) 

merkle syrup  10:42 AM
So how did we end up with segwit? Miners refused, NYA was meaningless, BIP148 happened and then everything changed

Jeremy Rubin  10:43 AM
P --> Q does not mean Q --> P
10:43
further if you want to put BIP148 on a pedestal
10:43
why did BIP148 include a PoW change in it's planning?

merkle syrup  10:43 AM
How did segwit happen?
10:44
Why did miners activate segwit?

Jeremy Rubin  10:45 AM
Clearly the answer is we merged a buried deployment noncontroversially much later ;)
10:46
You can't concretely prove what happened, nor can you even make a strong epistemic argument. There's 0 repeatability, and too many confounding variables. AFAIU, segwit activated because of BIP9
10:46
And as I've discussed in my Spork talk, designs like BIP9 are bad precisely because they give parties incentive to self aggrandize their importance to the process in order to claim more influence
10:47
If BIP-91 was so important, why did it aim to be BIP9 compatible?
10:47
Why not just activate it via 91 entirely?

Aaron van Wirdum  10:47 AM
I find this position that miners coincidentally started signaling just before the BIP148 deadline very unconvincing personally. (Very unconvincing.)

Jeremy Rubin  10:47 AM
Clearly bip9 is what mattered

merkle syrup  10:47 AM
Sorry this is an absurd claim :confused:
10:47
And self evidently wrong

Jeremy Rubin  10:48 AM
OK
10:48
Look, why did BIP148 include a PoW change?
10:48
It was clearly part of the roadmap

merkle syrup  10:48 AM
That is a completely irrelevant discussion

Jeremy Rubin  10:48 AM
Why was that required?
10:48
No it's the main discussion here?

merkle syrup  10:48 AM
We are discussing what motivated the miners to activate via BIP9

Jeremy Rubin  10:48 AM
There's a real chance you won't actually see this convergence you think

merkle syrup  10:49 AM
They had a long time to do it, they didn’t until users threatened to reject blocks which didn’t do it
10:49
Before time was up, they switched
10:49
Reasonable conclusion: UASF game of chicken was total victory for UASF side.

Aaron van Wirdum  10:49 AM
There are two position that I can take seriously: 1) BIP148 did the trick, 2) Segwit2X did the trick (before it was abandoned.) But 3) It was a coincidence... nah.

Jeremy Rubin  10:49 AM
the scenario is totally different from the scenario today BTW!

merkle syrup  10:50 AM
Not really. And there are a bunch of things that are better. Timeframe is not rushed.
10:51
Plus previous success of a UASF
10:51
Feels way less ambiguous.
10:52
I’m just gonna say it - I don’t think you actually understand the mechanisms at play here :confused:

Jeremy Rubin  10:52 AM
refer y'all to read https://en.wikipedia.org/wiki/Scientific_method and https://en.wikipedia.org/wiki/Epistemology

merkle syrup  10:53 AM
The opposite of science is trying the same thing expecting different results. We’ve tried optional signalling for miners and it didn’t work. We tried mandatory signalling and it worked. Part of the frustration with ST/BIP9/MTP/Lot=false etc is that we have tried this before and it didn’t work.
10:53
:shrug: I gtg for a bit

Jeremy Rubin  10:54 AM
I strongly encourage you to read the wikis linked
10:56
btw that's not an actual einstein quote
10:56
science is largely based on trying the same thing multiple times for repeatability
10:57
and science tries desprately to control for differences between iterations
10:57
so that you can generalize
10:57
generalizing from non repeatable experiments is lawl

Aaron van Wirdum  10:58 AM
Jeremy: Do you have an opinion on praxeology?

Jeremy Rubin  10:58 AM
I tried to go to the bakery on monday, but it was closed. Therefore it is always closed. That's what y'all sound like

Aaron van Wirdum  10:59 AM
No, it's more like: I'm predicting that BIP148 will make miners do X. And then miners did exactly X. (edited) 

Jeremy Rubin  11:00 AM
I think that praxeology is a bit like observing a quantum state if that makes sense. I can explain if you're interested

Aaron van Wirdum  11:01 AM
Sure.

Jeremy Rubin  11:01 AM
So think about "behavior" as like observing light
11:01
We form some empirical views about how light behaves
11:01
Praxeology is a double slit experiment
11:01
if you have tight experimental controls, you can show behavior
11:02
Further, a praxeological realization is a permanent double slit for society
11:02
in the same way that e.g. an NP-complete problem can be "impossible" to solve, but if we had a solution we'd use it
11:03
Solving a NP-hard problem and showing a NP-completeness constructively can permanently change human behavior
11:03
Because the new knowledge of how to do something more efficiently conditions us to do so
11:04
But w/o the knowledge and solution, (e.g., if only I know it), others cannot solve it
11:04
and therefore w/o such a solution behavior doesn't change
11:04
The "solution" is essentially the slit that forces observation
11:04
Does that make sense?
11:05
I can give a basic example

Aaron van Wirdum  11:05 AM
ok

Jeremy Rubin  11:05 AM
do you remember the first time your parents told you "hey, here's a cookie for you to share with your sibling"
11:05
And then you fought about how to share it
11:05
and then your parent said, "Aaron splits, X chooses"
11:05
and then you were like Oh shit!
11:05
That works!
11:06
before the introduction of a mechanism (which is beyond most children), you don't know how to achieve an equitable outcome and you just poke each other in the eye
11:06
But after, like magic, you see cooperation
11:07
So empiricism can measure "what happens if we give 2 uninformed children cookies and ask to share"
11:07
And praxeology can say "rational children would do X".
11:08
Empiricism can test praxeological theories by controlling for knowledge of rational behaviors

Aaron van Wirdum  11:08 AM
Well that's pretty difficult in economics, but go on.

Jeremy Rubin  11:08 AM
But there are all sorts of weird experiments where even profit maximizing doesn't work as a proxy for rationality.
11:08
E.g., there are these group bias experiments where kids get told they are either skilled or unskilled
11:09
and then they will do all sorts of things to punish the kids in the other group for no advantage to themselves or even at some harm
11:09
so it points to some higher order human social dynamics that are very hard to quantify
11:11
I'm not sure this is helpful to you?

Aaron van Wirdum  11:13 AM
Yes, well I'm not sure that praxeology == is profit maximizing... in fact, it isn't. (If someone values laying on the beach over working in an office for pay, that's perfectly compatible with praxeology.) But maybe that's a detail.
11:14
I guess the more general question would be, what do you think incentivizes Bitcoin miners? Is it profit maximizing, or is it something else? (Or do you think I'm asking the wrong question in this context?)

Jeremy Rubin  11:14 AM
I think it's a great question
11:14
I generally categorize it as an exogenous behavior
11:15
Miners have some set of incentives, and we should analyze based on what picking those phenotypes from a distribution

Aaron van Wirdum  11:15 AM
Do you make any assumptions on what these incentives are? (edited) 

Jeremy Rubin  11:16 AM
it's sort of a limitation of econ modeling
11:16
You have to define some set of base phenotypes
11:16
this gets back to the whole NP-complete issue
11:17
If a new phenotype can be found with a SAT solver, then it can change your outcomes

Aaron van Wirdum  11:17 AM
I recall there was actually a mailing list post about this back in these says.
11:17
(These days = 2016/17)

Jeremy Rubin  11:17 AM
Have you every attended the chicago blockchain conference?
11:17
I'd highly recommend it

Aaron van Wirdum  11:17 AM
no

Jeremy Rubin  11:17 AM
it's hosted by booth
11:17
and i learned a ton about how economists tackle these problems formally
11:18
(and also about how stupid they think econometrics is :slightly_smiling_face: )
11:18
(and that describing someone's work as sophisticated is the ultimate burn)

Aaron van Wirdum  11:19 AM
I guess another question would be, how do you propose we find out what incentivizes miners? (Or more broadly, how incentives align in an ecosystem like Bitcoin.) If you prefer empiricism, the best thing would be for eg. UASFers to try again and study the results, right?

Jeremy Rubin  11:21 AM
btw can't find the ML post

Aaron van Wirdum  11:22 AM
@adam3us Do you remember this 2016/17 ML post where someone categorized different types of miners and their incentives, based on long-short term preference etc? I think it may have been your post, or maybe you just shared it on Twitter or something. (For some reason I have a vague association with you and this email.) (edited) 

Jeremy Rubin  11:22 AM
My general preference is to make minimal assumptions about behavior and discuss range of outcomes possible based on distributions of those revealed preferences and plan accordingly
11:23
This is why I'm asking questions like "what do you do if you have single digit hashrate permanently"
11:23
It's slightly more robust of a model IMO because it makes no arguments about why miners have that preference, just that they do
11:24
I want Bitcoin to be robust whether or not we perfectly understand incentives for miners to upgrade. (edited) 
11:25
Part of that includes discussing what you would do across possible distributions of revealed preference
11:25
keeping in mind that revealed preferences from 5 years ago don't tell us much about revealed preferences today

Adam Back:blockstream:  11:27 AM
@aaronvanw yes i wrote that on bitcoin-dev

Aaron van Wirdum  11:27 AM
Oh it's not like miners were polled or anything, it was just general speculation of possible types of incentives.
Eg. some miners will 51%-attack if given the chance, some care more about long-term health of the network.

Adam Back:blockstream:  11:28 AM
another interpretation btw of 148 (which I don't favor) is that miners realized that users were going to rekt themselves and felt embarrassed for them and worried about the chaos this would cause. so they avoided disaster at the 11th hour by running 91.

Aaron van Wirdum  11:28 AM
Haha Jihan would have loved users recking themselves more than anything in the world I think. (edited) 

Adam Back:blockstream:  11:28 AM
similar logic but different balance of power. elected to avoid mutual assured destruction but different retelling of who actually had the upper hand in this model
11:29
there maybe people with both views :slightly_smiling_face: clearly there are people around who learned nothing from UASF. like voorhees it seems etc

Jeremy Rubin  11:29 AM
@adam3us do you have the title of it? or a link?
11:29
would be grateful to read it
11:30
@adam3us I also think that's not likely, but thanks for sharing that interpretation. I think it's useful here in that we don't have strong evidence to suggest either, just a hunch. It's very hard to get generalized knowledge out of such events

shinobimonkey:uasf:  11:32 AM
This whole conversation is analogous to taking a turn on the freeway next to a massive cliff, and instead of discussing what you're going to do after making the turn and getting off the freeway, someone loudly and obnoxiously started screaming from the backseat what everyone will do if the driver decides not to turn and go over the edge of the cliff.
11:32
@jeremy you continue to just concern troll over ridiculous scenarios with absurd premises that you refuse to declare explicitly outright, because if you do they look utterly absurd

Adam Back:blockstream:  11:33 AM
@jeremy clearly there are people around who really disagree that miners abandoned/chickened out. i think they're confused.

Jeremy Rubin  11:34 AM
I think i've been relatively explicit?

Adam Back:blockstream:  11:34 AM
(really pools, not miners) but also i don't think the pools had their heart in it - it wasn't their fight  mostly (other than jihan) and they were lobbied as a proxy by big block retail payment companies

1 reply
Today at 11:37 AMView thread

shinobimonkey:uasf:  11:34 AM
https://twitter.com/JeremyRubin/status/1385812425316831235?s=20
Jeremy RuⓑinJeremy Ruⓑin @JeremyRubin
Types of Basic question are things like:
1) if you get < X% hashpower, will you wait for blocks; hard-fork PoW consensus; or hard-fork off of UASF?
2) Under what conditions would a forked +taproot chain be less valuable
3) What will you do if your chain has reorgs because < hash
TwitterTwitter | Yesterday at 9:26 PM

Jeremy Rubin  11:34 AM
Anyways if people just want to scream at me here, by all means.

shinobimonkey:uasf:  11:34 AM
https://twitter.com/JeremyRubin/status/1385812420577226754?s=20
Jeremy RuⓑinJeremy Ruⓑin @JeremyRubin
FWIW I'm going to mostly stay quiet (if I can...) on UASF related stuff here on out.
I've engaged in good faith on trying to get answers, but honestly I'm disappointed.
TwitterTwitter | Yesterday at 9:26 PM
11:34
you said you'd stop concerrn trolling, you haven't

Jeremy Rubin  11:35 AM
I was pinged in here by @orfanminer

shinobimonkey:uasf:  11:35 AM
2. all your premises are built on absurd worst case failures of ST
11:35
that you will not actually clarify framing that way, you just leave implicit

Jeremy Rubin  11:35 AM
Yes, I (perhaps shockingly) care more about what can go wrong than what can go right?

shinobimonkey:uasf:  11:35 AM
and you also refuse to acknowedge that in any of your worst case absurd failure modes for ST, they undermine the notion of trusting miners and miner signaling period (edited) 

Jeremy Rubin  11:35 AM
I want bitcoin to be super ultra mega secure

shinobimonkey:uasf:  11:35 AM
and the  entire argument for even activating anything through such a mechanism

Aaron van Wirdum  12:20 PM
@jeremy I don't mean to drag this on too long (I have other things to do as well), but do you think it's at least possible that UASFers are "right"? (Right about their assumptions around incentives, user/miner behavior, etc.)

Jeremy Rubin  12:20 PM
Oh sure
:white_check_mark:
1

12:21
but it's also possible the inverse
12:21
so don't take that out of context

Aaron van Wirdum  12:21 PM
Do you have any sort of probability in your mind? :slightly_smiling_face: Just out of curiosity.

Jeremy Rubin  12:21 PM
but i wouldn't go as far as to say they're implausible, or provably untrue
12:22
probability of what?

Aaron van Wirdum  12:22 PM
That UASFers are "right".

Jeremy Rubin  12:23 PM
it's hard for me to give you an explicit personal estimate of confidence number without knowing exactly what that entails
12:23
e.g., I think probability miners activate during ST is roughly the same with or without UASF
12:24
So that would be either a "0" or a "0.5" depending on how you frame the question
12:25
but this is just my opinion, which I think outside of yourself, no one cares to hear
12:25
i could be wrong on that too though'

Aaron van Wirdum  12:30 PM
I didn't have a specific question in mind, I was just sorta thinking out loud myself, but I guess I'd formulate it like, "LOT=true will compel miners to activate any otherwise-non contentious soft fork", or "BIP148 compelled miners to activate Segwit". (edited) 

Jeremy Rubin  12:31 PM
I guess a good question is will LOT=true compel miners to activate a contentious soft fork? E.g. would it have worked for SegWit.
12:32
So slightly different than your original posing?
12:33
I'd certainly like to imagine that for a contentious fork that's actively bad, the GT is not strong enough that the existence of the (to use your turn of phrase) "non wipeout" chain with an odious upgrade wouldn't make miners enforce it
12:34
E.g., would LOT=true work to decrease the block size?
12:35
Certainly how miners feel about taproot itself is a fully exogenous variable, you could make the case that block size decrease is endogenous but I think reasonable miners could disagree on it's long term impact, so let's say those are both exogenous.

Aaron van Wirdum  12:38 PM
I think any contentious soft fork can be countered with a counter-soft fork. Could be as simple as a checkpoint, but I personally prefer the anti-LOT=true idea Jorge Timon proposed. (Where nodes start the reject the blocks if they do signal for activation.)
12:38
So in that case both sides of the chain don't have wipeout risk.
12:38
So no, my question is pretty specifically about otherwise-non contentious soft forks, actually :slightly_smiling_face:

Jeremy Rubin  12:40 PM
I guess my question on applicability is that if (and I don't nesc agree, just working w/ your assump) that BIP148 worked for segwit, and segwit was contentious, it's not clear that a similar mechanism is implied to work for a non-contended upgrade. You need another assumption that non-contended upgrades are somehow a subset of contended ones
12:40
but that's a bit abstract?
12:41
Seems somewhat reasonable to me to expect that there's a point to point "hardness" on non-contended to contended

Aaron van Wirdum  12:41 PM
I don't think Segwit was contentious, I think not adding a hard fork was contentious, but that wasn't a soft fork.
The opponents of Segwit (+hard fork) hadn't considered these kinds of solutions.
(edited)

Jeremy Rubin  12:42 PM
this is sort of confirmatory that preference on segwit should be looked at exogenously
12:43
I don't think there is a paper rational reason (ignoring asicboost) to reject SegWit
12:43
But people formed some sort of political opinion about things, which is hard to model
12:43
Do you believe ASICBOOST was irrelevant?

Aaron van Wirdum  12:48 PM
(Sorry slow response, pizza man at the door.)
Yes, I think ASICBOOST was irrelevant when it comes to non-contentious, because I don't think miners have a say in consensus.
Do you think the objections of miners are relevant in consensus? (As in, non-contentiousness.)

Jeremy Rubin  12:50 PM
Yes? Miners make a tangible, irrevocable investment in the security of the network. Disrupting their investment in securing Bitcoin increases the risk for future investment capital in mining, which decreases security of the network.

Aaron van Wirdum  12:50 PM
Yes but that's a choice for users to make imo.

Jeremy Rubin  12:50 PM
That said, I think miners also work at the pleasure of Bitcoin, so there's only so much their opinion should matter on, and if they no longer server bitcoin users (e.g., empty blocks) then they are a bug
12:51
I agree it's a choice for users to make, as above. How do you propose you collect feedback from the miners so the users at least know what their preference is?
12:52
i.e. if ASICBOOST were really the main issue with SegWit, and we used ST, the ST would have failed, we would have asked "why" / whoever figured it out would have published, and we could have moved the witness commitment

Aaron van Wirdum  12:52 PM
I have nothing against miners, happy to listen to their wishes and concerns, I just don't think they have a say in consensus, that's all.

Jeremy Rubin  12:53 PM
Then why have miners at all?

Aaron van Wirdum  12:53 PM
To order transactions.

Jeremy Rubin  12:53 PM
e.g. why not use SCP

Aaron van Wirdum  12:54 PM
SCP?

Jeremy Rubin  12:55 PM
"Stellar Consensus Protocol". It's a pretty decent byz fault tolerant  consensus algorithm overall; ignoring the coin underneath. It is also (contrary to how some describe it) open membership set, so it isn't a fixed set of validators. (edited) 
12:56
every user picks their own validator circuit independently should they want to, there is a default though.
12:56
and you still don't accept invalid blocks, just used for txn ordering

Aaron van Wirdum  12:57 PM
Never looked at it. PoW works fine though.

Jeremy Rubin  12:57 PM
:cop:
12:57
halt!
12:58
Why does PoW work fine?

Aaron van Wirdum  12:58 PM
Sybil resistant, mostly.
12:59
Plus decentralized.
1:00
(Not as decentralized as it ideally would be in the current ecosystem, but hey we can hope for a better future.)

Jeremy Rubin  1:06 PM
Ok, so miners do have a say when it comes to their fulfillment of those properties?
1:07
(could be others props too, I mainly think about non equivocation as the main benefit)
1:10
I think miners do have a say (by virtue of knowing their business -- praxeological question I guess, maybe then need to be shown logic) on if it's still economic for them to provide those benefits to users.
1:10
users also have a right to say your benefits suck and we don't want them anymore
1:10
users rights, I agree, supercede miners
1:11
since as noted miners serve at the pleasure of users
1:11
but it doesn't mean that within the scope of how bitcoin works today it doesn't matter
1:11
and it's this precise point which is why in my email to bitcoin-dev, and my questions about uasf, I'm asking what do you do if users no longer want miners benefits

Aaron van Wirdum  1:16 PM
Are we splitting hairs about definitions (eg. what does "have a say" mean?), or do we actually disagree on something?
IMO users define the rules, miners mine within these rules. If miners have an opinion about the rules, users can listen to that opinion... and then users can choose to change/not change the rules accordingly, or they can ignore whatever miners want. (edited) 
1:17
"the rules" are basically the consensus rules, ie. "consensus". So miners aren't part of consensus.
1:20
Therefore, within consensus, getting rid of covert ASICBOOST wasn't controversial. It only benefited some miners. It benefited no users. (Quite the opposite, in fact, since ASICBOOST harmed decentralization). (edited) 

Jeremy Rubin  1:31 PM
No I think we're agreeing
1:31
I disagree about ASICBOOST
1:34
aj.txt 
Eventually the patent gets revealed, though, just as covert ASICBoost
did. Either NDA's expire, something violates them, someone rediscovers
or reverse-engineers the idea, or the patent holder decides it's time
to start either suing competitors or advertising.
Click to expand inline (40 lines)



1:34
a snippet from AJ
1:36
bluematt(2016).txt 
I think everyone understands that there will always be some ability to
iterate on ASIC designs, however, a patented optimization breaks that
assumption. Instead of being freely able to optimize their ASIC design,
patented optimizations require that people who discover such
optimizations themselves do not use them, giving one
Click to expand inline (11 lines)



1:37
Timo (ASICBOOST Patenter IIRC) 
This is what I meant. If existing hardware gets forked-out it will inevitably lead to the creation of an altcoin. Simply because the hardware exists and can't be used for anything else both chains will survive. I was only comparing the situation to a contentious hardfork that does not fork out any hardware. If the latter one is suspected to lead to the permanent existence of two chains then a hardfork that forks out hardware is even more likely to do so (I claim it's guaranteed).



1:40
praxeology guy (whole email is interesting btw) 
===============================
Praxeology Guy's Recommendation
===============================
Make it a policy that patent encumbered PoW optimizations are countered/prevented if possible while minimizing the disruption on the utility and availability of optimized mining capital equipment.  Owners of Bitcoin should support and activate the proposed PoW policy change by Gregory Maxwell as soon as possible to counter the ASICBOOST patent encumbrance... unless the creators of the ASICBOOST patent transfer their IP to the public domain.  SegWit should not be delayed for the purpose of being generous to those who first implement ASICBOOST in their mining operations.  Future ASICs and mining equipment should be made with the option to run without optimizations that make assumptions about policy that is subject to change in a future soft fork.



1:42
The main issue was not that only some miners benefitted or that it was secret, it's that it was patented
1:43
If it were just "by golly bitmain ASICs/Firmware work well", it would be more ok.
1:44
but I think this is a side quest...

Aaron van Wirdum  1:44 PM
when covert ASICBoost became widely known, that was a "reasonable,
directed objection" to segwit -- it made real mining hardware less
efficient.
I disagree with AJ there. It's not a reasonable objection from the perspective of users. (The perspective that matters.)

Jeremy Rubin  1:44 PM
Why not?

Aaron van Wirdum  1:44 PM
Yes agreed this is a sidequest! :slightly_smiling_face:

Jeremy Rubin  1:45 PM
I'm a user, AJ is a user, we both think it's a reasonable objection?
1:45
"this hurts our ROI"

Aaron van Wirdum  1:45 PM
I don't think it's reasonable.
No "our ROI" is something miner would say, not a user.
1:46
I'm only taking user perspectives into account, because we're talking about consensus rules.

Jeremy Rubin  1:46 PM
i meant the objection from the miner. The user's objection is "this hurts miners ROI"
1:46
I don't want to negatively impact mining ROI

Aaron van Wirdum  1:47 PM
No, a user cares about mining decentralization, not miners' ROI.

Jeremy Rubin  1:47 PM
Decreasing miners' ROI can be bad for decentralization.

Aaron van Wirdum  1:47 PM
Not in this case.

Jeremy Rubin  1:48 PM
That's not entirely clear
1:48
In this case the ROI wasn't the issue, it was the patents

Aaron van Wirdum  1:48 PM
Sure.

Jeremy Rubin  1:48 PM
The patents are sort of a social attack on bitcoin

Aaron van Wirdum  1:49 PM
Maybe we should discuss this another time, and move back to the main quest,
1:49
It's an interesting discussion, but kinda besides the point.

Jeremy Rubin  1:49 PM
Well I agree that users can decide whatever they want
1:49
But it's not in a vaccuum
1:50
They can't force miners to do anything directly

Aaron van Wirdum  1:50 PM
Right, so let's assume there is an otherwise non-contentious upgrade.
1:50
(Does Taproot qualify?)

Jeremy Rubin  1:51 PM
Sort of.
1:51
On the balance, yes

Aaron van Wirdum  1:52 PM
"If Speedy Trial is missed, and Bitcoin Core continues to do nothing, LOT=true will compel miners to activate Taproot"
1:52
Probability estimate?

Jeremy Rubin  1:52 PM
what % hashrate signalled during ST

Aaron van Wirdum  1:52 PM
0%

Jeremy Rubin  1:53 PM
then i'd say it's relatively unlikely that LOT=true compels miners to form blocks enforcing taproot

Aaron van Wirdum  1:55 PM
Actually scrap my last question.
What is "relatively unlikely?" 0%? 1%? 10%? 50%? I know this isn't exact science, just curious what your estimate would be.

Jeremy Rubin  1:56 PM
so part of the tough thing IMO is that there are some other factors:
mining is dynamic membership, 15 months later at LOT time could be very different from ST time
1:56
2. miners might want to dunk on ST
1:56
3. miners might want to cause the LOT people to get forked by signalling in Nov after minactive and then not doing taproot
1:57
but overall across those 3 concerns

Aaron van Wirdum  1:57 PM
Actually what was the % of hash power signaling for Segwit before BIP148? I think it was pretty low. Below 50% Maybe 30% or so...
1:58
Maybe that would be a more realistic number to pick for this hypothetical. (Instead of 0%)
But anyways, continue... (edited) 
2:00
26% in november 2016. https://bitcoinmagazine.com/business/where-bitcoin-mining-pools-stand-on-segregated-witness-1480086424
Bitcoin Magazine: Bitcoin News, Articles, Charts, and Guides
Where Bitcoin Mining Pools Stand on Segregated Witness
For the first time, bitcoin miners have been able to signal support for SegregatedWitness this past week. Developed as a soft fork, the proposed centerpiece of (200 kB)
https://bitcoinmagazine.com/.image/t_share/MTc5Mjk3NzYxMzkyNzk3Mzc5/where-bitcoin-mining-pools-stand-on-segregated-witness.jpg

Jeremy Rubin  2:00 PM
I guess I'm trying to figure out "how do we know"
2:00
re: "compels miners to activate Taproot"
2:00
like is it just "it happens"

Aaron van Wirdum  2:00 PM
That aligns pretty nicely with the end of Speedy Trial I think? So let's say 26% signaled during Speedy Trial.

Jeremy Rubin  2:00 PM
or if we hit the LOT period that it does happen?

Aaron van Wirdum  2:01 PM
If it happens before the LOT period, that counts.
2:01
So after Speedy Trial, before LOT, with no extra action from Core.

Jeremy Rubin  2:03 PM
Hmm

Jeremy Rubin  2:03 PM
And we don't count scenario 3


2 replies
Last reply today at 2:10 PMView thread

Jeremy Rubin  2:03 PM
also btw

Jeremy Rubin  2:03 PM
image.png 
image.png



1 reply
Today at 2:10 PMView thread

Jeremy Rubin  2:03 PM
I'm curious for the argument that it was UASF that was the loaded gun, and not NYA
2:04
but i just found this chart on reddit so not sure it's accurate

Aaron van Wirdum  2:06 PM
The NYA client, btc1, merged BIP91 under pressure of BIP148. Other than BIP148, there was absolutely no reason for them to merge BIP91.
Then, miners started signaling for BIP91 and enforcing it. Were they really running btc1, though? I seriously doubt it.
No I think it was all a face saving show to pretend it wasn't because of BIP148.
That said, I can at least take the position "it was due to NYA" seriously. (As opposed to, "they started signaling just before Aug1 out of coincidence".)
:+1:
1


Jeremy Rubin  2:07 PM
TBH i think this gets back to praxeology vs empirics to an extent
2:08
one could argue that what caused segwit activation was schelling point around confusion

shinobimonkey:uasf:  2:08 PM
empirically every miner I have talked to did not run bc1 at any point

Jeremy Rubin  2:09 PM
anyways @aaronvanw I think it's hard for me to give you some sort of estimate
:cry:
1


Aaron van Wirdum  2:10 PM
replied to a thread:
image.png
The graph conflates different types of "signaling" btw, fwiw.
2:12
Segwit signaling -> actual soft fork signaling
NYA signaling -> just miners adding a string with their opinion in the coinbase
UASF signaling -> what kind of nodes were on the network
BIP91 signaling not included (edited) 

Jeremy Rubin  2:13 PM
It really just depends what miners exogenous choice is at that point. And it could basically be a coinflip on if let's say 25% UASF miners get lucky to orphan the first invalid block
2:13
E.g., imagine I configure my pool to switch to UASF if I see an orphaned block (reqs mining 2 blocks)
2:13
if that's the dominant strategy, then it would be a matter of two coinflips on UASF hashrate to drive that
2:14
the other side would be if the non-UASF is lucky at the first nonsignal block, then UASF never catches up to most work
2:15
It's not clear to me that most miners will have any view other than being on the most work chain. I also doubt reorgs > 1 day are likely.

Aaron van Wirdum  2:15 PM
What if futures markets indicate that the UASF chain will be more valuable?

Jeremy Rubin  2:16 PM
What are the miners goals?
2:16
I think that miners could try to sneak into a big position to stack more sats

Aaron van Wirdum  2:17 PM
My assumption is that they want to make money. I think that's a reasonable assumption. But I'm open to other suggestions.

Jeremy Rubin  2:17 PM
Sure, it's not clear to me that "make the most money" and "mine the chain favored by prediction markets" are the same thing
2:19
I believe this is called throwing a game in sports betting.

Aaron van Wirdum  2:20 PM
Well, it will take at least two weeks before there could possibly be Taproot outputs to steal.
2:20
Longer if miners activate shortly after Speedy Trial.
2:21
And even when there are Taproot outputs to steal, that will be one miner stealing one block full... the next miner would presumably go back to mining the most valuable chain, and reorg the theft chain in the process.

Jeremy Rubin  2:22 PM
let's ignore stealing

Aaron van Wirdum  2:22 PM
Anyways I do agree that incentives could get funky as time moves on, and UASFers are an economic majority, Core does nothing, etc.

Jeremy Rubin  2:22 PM
just in terms of match fixing
2:22
I don't see the proof that a future market guarantees what miners do

Aaron van Wirdum  2:23 PM
Why not?

Jeremy Rubin  2:25 PM
can you walk me through how match fixing has no profitable (or even unprofitable but nash) conditions?

Aaron van Wirdum  2:25 PM
You bet against yourself and lose intentionally.

Jeremy Rubin  2:26 PM
yep

Aaron van Wirdum  2:27 PM
Futures markets != betting on what miners will do
2:28
So they can't bet against themselves, if that's what you're suggesting. (edited) 

Jeremy Rubin  2:28 PM
of course they can

Aaron van Wirdum  2:29 PM
How?

Jeremy Rubin  2:29 PM
Ok let's say that there's 10% A and 90% B
2:30
miners can sell B and acquire A

Aaron van Wirdum  2:30 PM
We're talking price, right?

Adam Back:blockstream:  2:30 PM
A sounds like BCH, in which case they lose if A isn't what users want
2:31
A proceeds to fall to 1%
:white_check_mark:
1


Aaron van Wirdum  2:31 PM
Can we make it concrete, that's easiest. (For me, at least.)

Jeremy Rubin  2:31 PM
uh
2:31
ok there's $10,000 A and $40,000 B

Aaron van Wirdum  2:31 PM
Which one is the UASF?

Jeremy Rubin  2:31 PM
i dunno it doesn't matter does it

Aaron van Wirdum  2:32 PM
I think it might, but OK go on if you think it doesn't. (edited) 

Jeremy Rubin  2:32 PM
I am a miner, and I sell 1 unit of B and purchase 4 units of A

Aaron van Wirdum  2:33 PM
Cool, they create a bargain for users to sell A for B.

Jeremy Rubin  2:33 PM
Now assume every miner does this

Aaron van Wirdum  2:33 PM
More bargains for us.

Jeremy Rubin  2:34 PM
Then, 100% of hashrate is on A. Fork day hits. A builds blocks, B has no blocks

Aaron van Wirdum  2:34 PM
Miners mine at a loss.

Jeremy Rubin  2:34 PM
What if the total haul from futures market == 5 years of lossy mining?

Aaron van Wirdum  2:35 PM
haul?
2:35
They were just making dumb bets as far as I can tell.

Jeremy Rubin  2:35 PM
as in they dumped so much B

Aaron van Wirdum  2:35 PM
Like Adam said, it's like Bitmain betting everything on Bcash.
2:36
They just banktupted themselves and all users got an extra 1-20% extra bitcoin.

Jeremy Rubin  2:36 PM
Wait i'm confused

Aaron van Wirdum  2:36 PM
Well played Jihan /s

Jeremy Rubin  2:36 PM
Do you believe in praxeology or not?

Aaron van Wirdum  2:36 PM
I think it's the best approach when it comes to economics. (Not quite the same thing as "believe".)

Jeremy Rubin  2:37 PM
Because we're talking about a theoretical model where it's possible and you're citing a single event (not even empirically so)

Aaron van Wirdum  2:37 PM
Ok let's take a step back.

Jeremy Rubin  2:37 PM
IDK sounds like jihan didn't make the bet correctly
2:37
but a smarter jihan could have?

Aaron van Wirdum  2:37 PM
ok there's $10,000 A and $40,000 B
(edited)
2:37
Why is there a price difference to begin with?

Jeremy Rubin  2:37 PM
exogenous vs endogenous question

Aaron van Wirdum  2:37 PM
Because users favor B, right?
2:38
They value it about 4x as much as A, on aggregate.

Jeremy Rubin  2:38 PM
this is false
2:38
it matters what the depth of the market is
2:38
and there are rational reasons not to play
2:39
so it's not users, it is some users
2:39
For example, I had a client with 7000 BTC during the fork

Aaron van Wirdum  2:39 PM
of course liquidity matters, no argument there.

Jeremy Rubin  2:39 PM
and he didn't want to bet in the futures market
2:39
because it's a cautious wait-and-see

Aaron van Wirdum  2:39 PM
Yep yep no arguments there.
2:40
Well wait, I don't think I agree with the last part.

Jeremy Rubin  2:40 PM
Well that's what he wanted... he dumped BCH after the fork actually happened.
2:40
maybe he was irrational?

Aaron van Wirdum  2:41 PM
Ok yeah we should assume very liquid and trustless markets.

Jeremy Rubin  2:41 PM
no way
2:41
not willing to give you very liquid

Aaron van Wirdum  2:41 PM
Why not?

Jeremy Rubin  2:41 PM
That's a huge assumption

Aaron van Wirdum  2:41 PM
But if we do make that huge assumption, you agree with me?

Jeremy Rubin  2:42 PM
agree with you what?

Aaron van Wirdum  2:42 PM
That miners can't "game" the market.

Jeremy Rubin  2:42 PM
Oh no they still can

Aaron van Wirdum  2:42 PM
So let's start there.
2:42
How?

Jeremy Rubin  2:43 PM
If you don't know who the sucker is at a table, it's you
2:43
That's what I mean by wait and see approach

Aaron van Wirdum  2:43 PM
I know who the sucker is, it's the miner selling valuable coins for worthless coins because he thinks he can "game" the market.

Jeremy Rubin  2:44 PM
How valuable are your coins if you can't move them?
2:44
Remember, 100% of miners aren't mining your chain
2:45
Many users would not want to be in such a situation of not being able to transact

Aaron van Wirdum  2:45 PM
Hashpower follows price, not the other way around.
Don't take this the wrong way: but we had these kinds of arguments over and over with big blockers a couple years ago. (Where you're now the one taking the big blocker position, which you were scoffing at yesterday.)
2:45
Users have more patience than miners.
2:46
They just need to wait.
2:46
Miners have to actually burn money.

Jeremy Rubin  2:46 PM
Can you at least acknowledge that "it's impossible to fix the match" is a weak argument?

Aaron van Wirdum  2:46 PM
No.
2:46
You're assuming that price will follow hash power.
2:46
I fundamentally disagree with that.

Jeremy Rubin  2:47 PM
Ah
2:47
There's a big difference between "it is impossible" and "it is possible"
2:47
this gets back to endogenous vs exogenous
2:48
I think users have an exogenous preference around things like what chain has miners/hashrate on it

Aaron van Wirdum  2:48 PM
We've found our disagreement then.

Jeremy Rubin  2:49 PM
There's also an endogenous pressure -- which is that if users want to transact, they can only do so on the chain with hashpower, but I think that's lesser.
2:49
If users don't have such a preference, why pay to subsidize mining?
2:49
Why not switch to SCP
2:49
What secures bitcoin?

Aaron van Wirdum  2:52 PM
I'm not saying hash power is useless. I'm saying hash power follows price. I'm willing to pay for block space, as long as it's the type of block space that I'm willing to pay for. I'm not willing to pay for any block space.

Jeremy Rubin  2:52 PM
to be fair I probably disagree with you less than you think
2:52
My point is more or less that in order to keep consensus at he scenario we're in, you probably need to hard fork PoW
2:52
Or at least have that on the table

Aaron van Wirdum  2:53 PM
Or have patience. And/or willingness to mine yourself.

Jeremy Rubin  2:53 PM
and not be attacked by the competing chain

Aaron van Wirdum  2:53 PM
PoW change is also an option though, sure.

Jeremy Rubin  2:53 PM
Bear in mind that it's not a 51% attack for them to rewind your chain

1 reply
Today at 2:54 PMView thread

belcher  2:53 PM
isnt SCP some shitcoin thing?
2:54
PoW is the only way

Jeremy Rubin  2:54 PM
@belcher read the scrollback

belcher  2:54 PM
i did

Aaron van Wirdum  2:54 PM
Stellar

Aaron van Wirdum  2:54 PM
replied to a thread:
Bear in mind that it's not a 51% attack for them to rewind your chain
?

belcher  2:54 PM
SCR is "stellar control something"? so an altcoin thing
:white_check_mark:
1


Jeremy Rubin  2:55 PM
no no... it's just a consensus algorithm

Aaron van Wirdum  2:55 PM
Oh.

Jeremy Rubin  2:55 PM
@belcher did you? I defined it earlier and why it's relevant for Aaron much earlier

belcher  2:56 PM
yep i did
2:56
you must realize that "why even use PoW when we can use <some shitcoin protocol>" is a terrible point, i say this as someone who supports core and ST
2:56
have you heard that line of reasoning that every alternative to PoW ends up just replicating PoW

Jeremy Rubin  2:56 PM
@belcher that's not what I'm saying  at all
2:57
I'm asking Aaron to give me the reasons miners are relevant to consensus
2:57
Which Aaron says that miners have no say in
2:57
Which I disagree
2:57
If you think miners have no say in consnensus, I don't see why you wouldn't use SCP or something similar

belcher  2:57 PM
something else i saw on the scrollback which i think is important, the UASF chain has wipeout risk but it also has slow blocks, the two issues of wipeout risk and slow blocks are mirror images of each other
2:58
the UASF chain has slow blocks but no wipeout risk, the non-UASF chain has fast blocks but wipeout risk
2:58
so if the UASF chain has say 1% then it has very slow blocks which might make up for the no-wipeout-risk upside, and therefore it might still be rational to adopt the UASF-chain

Jeremy Rubin  2:58 PM
i also agree with that; if you look back wipeout has been defined to explicitly disregard other issues like slow blocks and attackability

belcher  2:58 PM
ultimately it all comes down to which side has more of the economy

Aaron van Wirdum  2:59 PM
I don't think they're mirror images belcher.

Jeremy Rubin  2:59 PM
e.g. at just 1% if you have 99% on the other it would make sense to attack the chain to disrupt economy

belcher  3:00 PM
im not sure about that @jeremy, because we see in practice bcash had that kind of hashrate ratio and none of the bitcoin miners ever 51% attacked it

Aaron van Wirdum  3:01 PM
Slow blocks are a problem for a while, but not that bad. There are difficulty adjustments. Miners would have to go out of their way to attack you, and profiting from it isn't that easy. They could also attack BCH but they never do. (Only the smallest of chains suffer attacks sometimes.)
Wipeout just means your money is gone. Moreover, it can happen even if miners are just following incentives, as soon as the UASF chain becomes more valuable. They don't have to go out of their way to attack you.

belcher  3:02 PM
difficulty readjustment can take a long time

Jeremy Rubin  3:02 PM
at 5% it takes a year to diff adjust

Aaron van Wirdum  3:02 PM
Bitcoin will hopefully exist for tens of thousands of years

Jeremy Rubin  3:02 PM
Also I think wipeout is unrealistic

belcher  3:02 PM
at 5% hashrate that presumably means the miners have judged just 5% of the economy to have adopted the UASF chain, if it stays like that then a wipeout wont happen

Jeremy Rubin  3:02 PM
after a day miners/users of the other chain would likely checkpoint

Aaron van Wirdum  3:03 PM
If it takes a year of inconvenience to keep the protocol free from corruption (eg.) that's well worth it in my personal opinion.

belcher  3:03 PM
corruption?
3:03
do you think the Core team is corrupt or something

Aaron van Wirdum  3:03 PM
I'm just spitballing an example. Think ASICBOOST or whatever.

belcher  3:03 PM
ah ofc, well back in 2017 even i was in favour of a UASF as were many more people

Aaron van Wirdum  3:04 PM
No no, wasn't talking about Taproot or Bitcoin Core specifically at all.

Jeremy Rubin  3:04 PM
Aaron what if users UASF a developer fund in?

Aaron van Wirdum  3:04 PM
But(!), yeah, maybe Bitcoin Core does become corrupt in the future, so that would be another example.

Jeremy Rubin  3:04 PM
Keep the project free from exchange grant funded devs

belcher  3:04 PM
(and worth mentioning, its likely that core would implement a UASF if ST fails, as always if a UASF has consensus then its fine)

Jeremy Rubin  3:06 PM
IMO UASF's are neutral at best, I don't think they're pro / ante bitcoin

belcher  3:06 PM
i suppose the most accurate way of saying the thing most people are against is as "UASF without consensus"

Jeremy Rubin  3:06 PM
it's not clear they won't be advocating bad things ever

Aaron van Wirdum  3:07 PM
belcher: there's only one reliable way to measure consensus imo. Deploy a UASF, create futures markets, see what users want.

Jeremy Rubin  3:07 PM
@belcher consensus economically defined could still be bad. E.g., everyone wants free lunch

belcher  3:08 PM
@aaronvanw just because something is hard to measure doesnt mean we have to settle for lesser ways of measuring it, in fact the "hard to measure" is a feature because its a side effect of bitcoin's privacy

Aaron van Wirdum  3:08 PM
I didn't say it's hard to measure, I explained how to measure it.

belcher  3:09 PM
futures markets are not that great, we could end up in a situation where yes the UASF future is worth more than non-UASF but both are worth way less than before because bitcoin's price fell due to a damaging chain split
3:09
futures markets dont always measure consensus accurately
3:09
@jeremy consensus doesnt allow you to break the laws of physics, that free lunch has to come from somewhere (edited) 

Jeremy Rubin  3:10 PM
free lunch == someone else's :slightly_smiling_face:

Aaron van Wirdum  3:10 PM
A futures market comes before any potential damaging chain split. And if it turns out the market doesn't want the UASF, that info will help prevent a chain split I think.

belcher  3:10 PM
ah i see what you mean, well presumably that someone else whos stuff you're stealing would object and therefore there wouldnt be consensus
3:11
@aaronvanw i dont know about preventing a chain split, since we see in the backlog people talking about that story of dancing close to the cliff edge, pretending to be retarded so that you "win"

Jeremy Rubin  3:11 PM
that's the diff between the "economic majority" and consensus
3:11
futures measure economic majority
3:11
but even then, they do a crappy job at that

Aaron van Wirdum  3:12 PM
@belcher And I also mentioned in the thread (a couple comments later) that I think futures market will defuse the "acting crazy on a cliff" trick. You either put up the money, or it's clear you're bluffing.

belcher  3:12 PM
@aaronvanw people might still run an alt-client even if the futures market is against them, thats what being crazy is about

Aaron van Wirdum  3:12 PM
So?

belcher  3:13 PM
then they would be using a different coin

Jeremy Rubin  3:13 PM
anyways we've been at this for a while -- hope this has been at all interesting for you @aaronvanw. I have other things to get to :slightly_smiling_face:

belcher  3:13 PM
btw i listened to your podcast @aaronvanw it was pretty good https://www.youtube.com/watch?v=SHmEXPvN6t4
YouTubeYouTube | Bitcoin Magazine
Taproot Activation Update: Speedy Trial And The LOT=True Client - The Van Wirdum Sjorsnado 


1 reply
Today at 3:14 PMView thread

Aaron van Wirdum  3:14 PM
@belcher I'm completely fine with minorities splitting off if they insist. Let's the rest of us sell the fork coins; everyone is happy.

belcher  3:14 PM
"im fine with minorities splitting off" = "im fine with a chain split" ?

Aaron van Wirdum  3:14 PM
@jeremy Yep, thanks Jeremy, good chat!

belcher  3:15 PM
cool i guess, id like to avoid a chain split if possible myself

Aaron van Wirdum  3:15 PM
Belcher: Yes no one is obligated to stay if they prefer to leave. I think incentives will ensure that not too many people will want to leave. Look at what happened to BCH.

belcher  3:16 PM
too bad @jeremy has gone i remembered something else wrong from the backlog: the NYA definitely was not the prime moving cause of segwit activation, but instead bip148 and i have lots of evidence to prove it (but he's gone so no point i suppose) (edited) 

Jeremy Rubin  3:16 PM
@aaronvanw might be worth exporting the chat log if you want to. otherwise will erased tomorrow

Aaron van Wirdum  3:16 PM
I don't even know how?
New
3:17
Or do you mean just copy/paste?