Reddit User Account Overview


Redditor Since December 4, 2015 (1,711 days old)
Karma Posts: 980 Comments: 5,689 Combined: 6,669
Active in

The BCH devs are the only ones that can free us from bitcoin's Achilles heel... The need for protocol development. Needing people to make themselves obsolete is a tricky dynamic. If they are paid too much, they won't want to ever become obsolete. If they are paid too little, it won't be worth their time and efforts to put the work in. How could devs be incentivized to make the protocol complete, and themselves obsolete, as fast and as good as they can? Put a big pot of gold at the end of the task! The devs that put time in already have ownership to "shares" and new work will earn more "shares". This allows current devs to leave the project at will and still be compensated for work already done at the completion of the protocol. However, the longer the task takes to be completed, and the more work that goes in to the task, the more thinly spread the pot of gold becomes. This incentivizes the incumbent (share-owning) devs to stay and complete the task faster, so they end up with more of the pot. The higher-quality the work is, the more utility and value BCH will have. This will increase the value of their shares of the pot when it's paid out. This incentivizes devs to do good work while completing the protocol, and not to do it fast without regard to long-term value of BCH. What do all of you think (especially any protocol devs, it's such an awkward topic)? Is this a good way to structure the BCH development fund that is collecting? I know it doesn't account for cost-of-living, I can't think of how to incorporate that and wanted to post this before I lost the nerve.

posted by /u/melllllll in /r/btc on May 31, 2019 20:15:57

Hi there, You've probably heard that the Bitcoin Cash (BCH) network is on track to experience a planned protocol change via a hard fork on November 15, 2018. Here's what you need to know about how this hard fork will affect your BitPay BCH payments:  ## What's happening with Bitcoin Cash?  BitPay's system uses the primary software implementation of Bitcoin Cash called Bitcoin ABC. Bitcoin ABC has scheduled a Bitcoin Cash protocol change via hard fork on November 15th.  While non-backward-compatible hard forks allow for rapid protocol innovation, they also carry a risk of creating a permanent split in a network. It is possible that Bitcoin Cash will experience this kind of split. This would create two versions of the Bitcoin Cash chain, resulting in disruptions for Bitcoin Cash payments.  ## What will BitPay do during the hard fork?  **To minimize risks to merchants and Bitcoin Cash users during the hard fork, BitPay will temporarily pause Bitcoin Cash payment processing.** Bitcoin Cash payments will be unavailable starting at **10 AM EST**, about two hours prior to the expected start of the hard fork. We will send an email update to you during the time of the fork and when BitPay resumes Bitcoin Cash processing. ## How will this affect my BitPay customers?  Your customers will see an error message if they attempt to pay with BCH during this downtime. They will be able to pay with Bitcoin (BTC) without interruption. ([picture of error message]( ## Will settlements be affected? What about customer refunds? BitPay will settle BCH merchant balances and continue to process BCH refunds as usual.  ## What will BitPay do after the fork?  BitPay has not made any plans to migrate from the Bitcoin ABC implementation of Bitcoin Cash to a different implementation. BitPay will closely monitor network conditions and the chains resulting from a chain split. **We will restore Bitcoin Cash payment processing when we are confident that your customers can pay securely.** Again, your customers will be able to pay with Bitcoin (BTC) without interruption.  Have any more questions about how the November 15th Bitcoin Cash fork will affect your business? As always, please [reach out]( to our customer success team.  Best,  **The BitPay Team** 

posted by /u/melllllll in /r/btc on November 8, 2018 14:07:32

We're dealing with two simultaneous hard fork updates, though. The legacy chain would arguably have an advantage, but which one is the main chain if they're both forks?

Commented by /u/melllllll in /r/btc on August 10, 2020 04:08:18

I get what you're going for, but for this meme to make sense there would have to be an 8% transaction fee.

Commented by /u/melllllll in /r/btc on August 10, 2020 03:09:56

I read a company had taken out huge short positions on LINK, and they got liquidated between $9 and $13. Foom! I don't expect it to stay that high in price, but I've been wrong before XD

Commented by /u/melllllll in /r/btc on August 10, 2020 03:05:27

Rofl, it's some guy's meme-producing project. He tips for BCH memes. The quality and usefulness (aka truthfulness) of memes one gets for promised tips versus someone just making memes for funsies is shockingly low XD But the volume of memes is out of this world!

Commented by /u/melllllll in /r/btc on August 10, 2020 02:57:29

It's up to miners which full node implementation they run. If you have some hashrate, you can point it to the one you prefer.

Commented by /u/melllllll in /r/btc on August 10, 2020 02:50:58

You can read into silence, but I will wait for an actual announcement.

Commented by /u/melllllll in /r/btc on August 9, 2020 02:33:48

Yeah, I guess that's a different dimension I'm looking at. I don't think consensus changes can be decentralized across multiple full node implementations without increasing the chance of a chain split. The miners request what they want from the software developers of their full node implementation, and then the team puts it together. It's not actually up to developers to decide on the consensus changes. They answer to miners (their customers) or their upgrades never get used. A second full node implementation doing its own work means they're intending to go find customers (miners) to use their product, or just be working on a product that doesn't get used (and there's not much reason to do that). If the two teams agree on all the consensus changes, what's to get miners from switching over to them? Their product needs to differentiate itself. This means having different consensus rules that they claim are superior. So they end up with an incentive *not* to agree with the other team if they have a separate product. So it's better to have devs all on the same team, or not doing consensus changes at all. You can see how it's not actually an issue of lack of a development process shared across teams, it's an issue of lack of incentives to agree across teams. BCHN's original purpose was to ensure that a split did not happen, and now they are making efforts to actually get a split to happen. They want to be used. Collaboration and compromise is simply not incentivized. Divide-and-conquer is a really effective tactic for external forces to destroy the whole bitcoin project, so I'm sure saboteurs are all up in this "community" encouraging a split right now.

Commented by /u/melllllll in /r/btc on August 9, 2020 02:26:26

I think and hope you're right.

Commented by /u/melllllll in /r/btc on August 8, 2020 22:43:58

Did they announce who has control of the single address?

Commented by /u/melllllll in /r/btc on August 8, 2020 21:17:02

Omg you're right, ethereum just split into two incompatible chains. Just like "decentralized development" inherently means, which is why protocol development shouldn't be decentralized. Unless splits are the desired outcome.

Commented by /u/melllllll in /r/btc on August 8, 2020 21:13:41

[Big pond](,24h) Ooh look it might clear this weekend. Don't worry, will fill back up.

Commented by /u/melllllll in /r/btc on August 8, 2020 21:08:18

I think it's the need for protocol development whatsoever. The incentive system set up to keep bitcoin sound doesn't cover protocol developers, so it's really dependent on holders to pay developers in order to do what needs to be done on the protocol. Within the actual protocol dev groups, they're fighting to be the top dev (or at least part of the top full node implementation) instead of following only economic incentives to increase the value of BCH as sound, global money. The IFP might partially solve this by putting part of miners' funds into a type of incentive system that financially incentivizes developers to increase the value of BCH. Someone does have to logistically structure the IFP to make these incentives line up, and this is what I'm waiting to be announced. Who holds the IFP address' private key? A foundation/corporation? An individual? It makes all the difference, and we just don't know yet. So you're right, and the IFP (the cause of the drama at the moment, ironically) is a proposed solution to the problem.

Commented by /u/melllllll in /r/btc on August 8, 2020 20:54:20

Block stream to create big pond.

Commented by /u/melllllll in /r/btc on August 8, 2020 20:47:22

They might not decide until more information is available, like what the actual options are and what other major players like Coinbase are doing. I'm not even sure tether needs to announce anything. They'll use whatever SLP tokens the major exchanges will support (because that's what SLP-tether needs in order to be valuable). So, like u said... they'll prob wait til dust settles.

Commented by /u/melllllll in /r/btc on August 8, 2020 20:38:41

>defer to the miners and to trust them to an extent. Yaaas! A lack of belief that this will work is a lack of belief in bitcoin itself. It sounds hokey, but that's what it boils down to for me. I guess I would actually say miners/holders, it only works so well because the biggest miners are the biggest holders.

Commented by /u/melllllll in /r/btc on August 8, 2020 20:17:43

I think hashrate just point to the pool it wants. The node operator has the powa.

Commented by /u/melllllll in /r/btc on August 8, 2020 20:15:22

I saw one that said even if the IFP private key is in the control of someone else, it is still in the control of Amaury XD

Commented by /u/melllllll in /r/btc on August 8, 2020 19:58:21

So who is "scrambling to run a full node"?

Commented by /u/melllllll in /r/btc on August 8, 2020 15:06:46

Their definitions are unclear. I'm gonna wait for a better listing.

Commented by /u/melllllll in /r/btc on August 8, 2020 15:02:35

Hashrate votes, not nodes per se. Listening-only nodes don't have a vote.

Commented by /u/melllllll in /r/btc on August 8, 2020 13:58:47

It wouldn't necessarily be Amaury asking him, but I would make a bet he'll be asked to join that board ;) XD

Commented by /u/melllllll in /r/btc on August 8, 2020 13:51:45

I think we should wait and see who (or what entity) has control of that single address.

Commented by /u/melllllll in /r/btc on August 8, 2020 13:48:45

Had to look that up :p Yes, there are a lot of assumptions being thrown around!

Commented by /u/melllllll in /r/btc on August 8, 2020 13:46:17

I hope IFP passes personally (though recognize it's up to miners and not to me, it's their money and their voting power). But the incentives for miners to implement IFP are weaker if it is paid out directly to the ABC team. The ones choosing to pay into the fund (let's call them "Jihan") would give up control of where the future funds go 6 months in advance (unless they did an emergency upgrade, which could happen). It's not a trustless setup, they'd be trusting the ABC team in that case. Also, just for getting a gauge on how much money this is, it's 72 BCH per day (26,280 BCH/year). At $300 that's $21,600 per day, about $7.9 million/year. *At current prices*. ABC was trying to raise $3.3 million, or 14,500 BCH, to [fund]( ABC, and they've got 55% of that already. There's over four times as much as they need to complete their fundraiser if IFP runs for 1 year. I don't think Jihan would implement the IFP if it went straight to BitcoinABC, it would be more impactful with a trusted corporation/committee distributing it as needed over the next years. Nobody can predict the future, somebody's gotta be a trusted custodian of the IFP proceeds, and it doesn't make sense to give that power away from himself and other non-recipients.

Commented by /u/melllllll in /r/btc on August 8, 2020 13:33:05

It could be done, but it would be a clear developer-initiated fork against majority hashrate. It is quite a twist. Then we'd be back in the BitcoinABC/BitcoinSV situation again, I hope it doesn't go against majority hashrate. Hashrate pays the 8% anyway, not developers. My hope is that the address is announced to go to a foundation so all the developers can benefit from it. Then the incentive for devs to force a split away from it is (even) lower. A double-viable split is just such a bad path forward, no matter how it's spun.

Commented by /u/melllllll in /r/btc on August 8, 2020 13:02:46

There are still some critical unknowns that might assuage some hurt feelz. Like where does the single address go? If it goes to a foundation, and some key BCH members are on its board, pretty much most of the resentment goes away. Everyone thinks it goes directly into ABC's payroll for some reason. It's Infrastructure Funding Plan, not Protocol Funding Plan.

Commented by /u/melllllll in /r/btc on August 8, 2020 04:32:43

I'm all in. Bitcoin Cat is the Real Dogecoin

Commented by /u/melllllll in /r/btc on August 8, 2020 02:37:36

Haipo make joke. E'rebody take serious. Bitcoin Cat fix all.

Commented by /u/melllllll in /r/btc on August 8, 2020 01:52:17

I guess I don't for sure. Since BitcoinABC will reject 100% of BCHN blocks, if BCHN miners are "RationalMiners" they'll mine with BitcoinABC until a split happens (10 BCHN blocks in a row, rolling checkpoint locked in). But the more BCHN-voting nodes switch to this, the less BCHN hashrate there is, and the less likely they'll EVER get 10 blocks in a row. So... I think I get your point now ;)

Commented by /u/melllllll in /r/btc on August 8, 2020 00:41:56

Ok, sorry, I don't mean to be combative. Tensions have been high :p

Commented by /u/melllllll in /r/btc on August 7, 2020 22:05:41

>I am imagining that most miners run a hypothetical "RationalMiner" client program, rather than the reference client. These attacks are not possible if more than half of the network are "honest" in the sense that they run the reference client. Doesn't this make it irrelevant for the upcoming situation? Neither node implementation is going to be a "RationalMiner"

Commented by /u/melllllll in /r/btc on August 7, 2020 22:03:44

It doesn't matter if we listen to them, is the beauty of it :) Majority hashrate decides in November.

Commented by /u/melllllll in /r/btc on August 7, 2020 17:46:32

The BCH chain, though. That can be true and they still could be an extreme minority of SHA256 hashrate.

Commented by /u/melllllll in /r/btc on August 7, 2020 15:15:50

Yeah, I'm not sure why miners would sign a paper statement instead of signal with their hashrate. Maybe they all point at pools and don't control the nodes they're mining on.

Commented by /u/melllllll in /r/btc on August 7, 2020 15:10:26

I don't hate anybody, so it's easier for me to see what's happening. I don't envy the career bitcoiners who can't take a month off from obsessing over bitcoin happenings whenever they need to. The emotions dissipate eventually. If you are able to stop hating individuals, the outcome of this update won't be so painful if it's not what you want.

Commented by /u/melllllll in /r/btc on August 7, 2020 15:00:32

Hey! Whoa! Anarchist? I'd call them collectivists at this point.

Commented by /u/melllllll in /r/btc on August 7, 2020 14:55:02

Posting my comment in isolation is disingenuous at best, and dishonest at worst. I was making fun of the previous comment's overly-dramatic wording: >You have a whole ecosystem that collaborates in an open and evidence-based fashion, and one party that does not. > >Blaming the whole ecosystem for failure of communication of one party is disingenuous at best, and dishonest at worst. You don't have to wait to find out what I have to say. "It's up to them, not me, not you." Ta da!

Commented by /u/melllllll in /r/btc on August 7, 2020 14:51:45

For sure feel better. Now everyone can flip out for 3 months and, if all goes well, it doesn't matter one tiny bit. There won't be a split, it will be a real hashwar this time!

Commented by /u/melllllll in /r/btc on August 7, 2020 14:46:48

What's your reminder for? If they in the future speak I was wrong that they hadn't in the past yet done it?

Commented by /u/melllllll in /r/btc on August 7, 2020 02:38:54

I'm not complaining, I went with the block size increase (BCH) and am content. Couldn't have done that without it being open-source so that's nice!

Commented by /u/melllllll in /r/btc on August 6, 2020 20:05:53

That would require a market for both coins, and in the absence of a sustained split (more than a day or so) there won't be a functioning market yet where they can deposit and sell them. There's a 100-block freeze also, so if the split is less than 100 blocks there's no coinbase reward that can be moved. Definitely a lot of factors here, never a dull day in bitcoin XD

Commented by /u/melllllll in /r/btc on August 6, 2020 20:00:45

Plot twist... The miners requested this. It is in line with their incentives exactly like curryandrice pointed out, and Bitmain is ABC's largest funding source so their requests would definitely be heard. They're not worried about losing the vote because their hashrate is a make-or-break amount of hashrate, they're just maneuvering so hashrate is the actual voting mechanism (and not the commitment of the businesses' infrastructure). Also this setup makes 51% attack threats obvious bluffs because the person could achieve the same result cheaper by participating in the vote.

Commented by /u/melllllll in /r/btc on August 6, 2020 18:37:41

If that's the case, I would guess ABC miners will switch to BCHN and accept losing the vote before committing to a chain split. Nobody actually wants a chain split.

Commented by /u/melllllll in /r/btc on August 6, 2020 18:15:06

I know that character, he's very incendiary :) I think if he ends up on the opposite side of Bitmain, he will decline mining at a loss. That's kind of the genius of this setup, it takes the wind out of 51% attack threats (like CSW made.) If a miner's gonna brute-force one way or the other, they're better off just joining the actual voting. Any sabotage threats are obvious bluffs because they're more expensive (a 51% attack still doesn't mine the chain you WANT, it just disrupts the chain you DON'T want, so it's a complete "waste" in that way)

Commented by /u/melllllll in /r/btc on August 6, 2020 18:10:08

Interesting. So if BCHN had 15% of hashrate and those people wanted to stick it out and split, they'd have to mine at a complete loss until that happened, right? Their blocks would be constantly orphaned until they got 10 (or 11) in a row? This could be a factor that gives IFP miners an advantage. They don't have to mine at a loss like this, they'd just have to manually switch once BCHN got 10 in a row (and then they'd lose whatever blocks they mined after the split).

Commented by /u/melllllll in /r/btc on August 6, 2020 18:01:18

The two upgrades have the exact same DAA fix, so businesses just need to implement that DAA fix to stay together. If I'm not mistaken, whether they're on the IFP protocol or no-IFP protocol doesn't affect their businesses since the only difference is where the coinbase goes and which blocks (non-IFP blocks) get orphaned if IFP is activated (IFP blocks won't get orphaned even if IFP is *not* activated because it's not a consensus change to re-direct some coinbase to an address). Miners will vote, miners will pay the 8% themselves if they vote "yes," businesses can officially stop paying attention and just implement the DAA. I am still figuring out how it works, so I might have made a mistake in there... Apologies if this turns out to be inaccurate. Edit: Actually if the IFP does not get activated, they'll end up building off only IFP blocks and the orphaned no-IFP chain will end up longer. So they'll end up getting orphaned in the end, just all at once when the other chain becomes longer, then those miners will have to manually switch to BCHN. But any BCHN node should follow the IFP-activated ABC chain without issue.

Commented by /u/melllllll in /r/btc on August 6, 2020 17:43:51

Blockstream's [Liquid patent]( is owned by the co-founders, two people, one of which is a core dev. The Liquid network is dependent on full blocks to have a use case. The incentives line up that the developer declined to remove the 1MB block size cap, intentionally causing the blocks to fill, in order to sell his product (Liquid network.)

Commented by /u/melllllll in /r/btc on August 6, 2020 17:31:01

Just to be devil's advocate, not to show a preference (I don't have one)... What if there is only one chain and it is the IFP-activated BitcoinABC chain?

Commented by /u/melllllll in /r/btc on August 6, 2020 17:16:19

;) It sounds like a useful idea, regardless of how this upgrade plays out.

Commented by /u/melllllll in /r/btc on August 6, 2020 17:12:59

I didn't appreciate him as much until this event started playing out. Giving power to the reddit mob would lead to the failure of BCH. The IFP seemed fine, miners were voting on it and miners were paying for it, but the mob went apeshit and I thought "What is going ON this isn't coercive, it's got a built in voting mechanism." I keep thinking about how genius this current move is. If somebody threatens a 51% attack against the IFP-activated chain, it will obviously be a bluff because if the had majority hashrate they would have just voted against the IFP with it, and saved a lot of money (51% attacks cost more than voting for the chain you want and winning). It eliminates the bluff 51% attack threat that CSW used during the BCH/BSV split!

Commented by /u/melllllll in /r/btc on August 6, 2020 17:04:18

Yeah, the poison-pill was confusing me for a bit, but it's just a terrible name for something completely benign. It's auto-replay protection, and if it were to be triggered (nobody upgraded anywhere and the "poison-pill" activated) nothing would happen to exchanges and wallets and such. They would all still be in operation if we skipped an upgrade, they'd just have unnecessary replay protection. I actually went and asked an ABC dev this, so even though I don't understand why it would be fine, they said it would not break anything.

Commented by /u/melllllll in /r/btc on August 6, 2020 15:10:59

In a different comment from you, you said "they're just biding their time" in reference to the IFP, and I thought "Nope, wrong, it's dead." You were right XD I need to read The Art of War so I can better appreciate these moves. I'm pretty entertained.

Commented by /u/melllllll in /r/btc on August 6, 2020 14:58:35

AbsoLUteLY. You just went to the 99th percentile of understanding bitcoin, and I thought you were new. The legacy chain advantage is what the core developers harnessed to block removal of the 1MB block size cap, and it's why they were able to win. We were in a no-change-breaks-bitcoin situation, they had legacy chain advantage, so even though miners were like "noooo!" the 1MB block size cap remained. If 1MB block size cap had been an alternate change instead of a no-change, they wouldn't have been able to force it through because the miners would have just declined to upgrade. If BSV was seriously opposed to CTOR, they would have released a no-change implementation and very likely won with the legacy chain advantage. Nobody wants a chain split, they are *very* expensive for the ecosystem to implement, so businesses/miners would have just declined to upgrade and bam. No CTOR. That's all someone needs to understand to know it wasn't about CTOR being bad, it was about BitcoinSV wanting to be the dominant full node implementation. Here's the catch, though... if nobody upgraded, BitcoinABC would have still been the dominant full node implementation. Nobody would have been *required* to switch to BitcoinSV's no-change implementation, and they wouldn't have had any additional control over getting new future changes in.

Commented by /u/melllllll in /r/btc on August 6, 2020 14:49:50

I'd call that a mutiny at sea :) I'm really digging adopting nautical rule here.

Commented by /u/melllllll in /r/btc on August 6, 2020 14:21:24

They'd have to upgrade at the same time, or one would be implemented on the network first and it would be game-over. If one was already live, nobody would bother to change to the other. The change is very labor-intensive to infrastructure (businesses and wallets and such) and they wouldn't want to deal with it *twice*. But I have good news for you, the exact same ASERT is now on both upgrade proposals so it's all but guaranteed. They are fighting about something else now :)

Commented by /u/melllllll in /r/btc on August 6, 2020 14:12:49

The tradeoff is if the multiple parties can't agree, there's stagnation. It's efficient to be centralized, that's why companies don't only have a board of directors but also a single CEO.

Commented by /u/melllllll in /r/btc on August 6, 2020 14:07:26

That sounds useful. I know the miners don't want anything to do with coordinating themselves to raise the max block size cap in unison, hence the importance of the default block size cap.

Commented by /u/melllllll in /r/btc on August 6, 2020 14:04:47

I'm pretty relieved, overall. These two choices are so much more similar that all the businesses can ignore the situation and implement the agreed-upon DAA. Whether or not the IFP goes through might not affect the wallets/businesses upgrades at all.

Commented by /u/melllllll in /r/btc on August 6, 2020 13:51:14

There we go! The team can democratically elect a "president" or "captain" or "chancellor" or whatever. Just not "dictator." The term can be 1 year, and then they'll go up for re-election. Hopefully Reddit is not the poll XD If we're gonna replace a dictatorship, let's replace it!

Commented by /u/melllllll in /r/btc on August 6, 2020 13:47:49

Saying the whole ecosystem collaborates in an open and evidence-based fasion is disingenuous at best, and dishonest at worst. The ecosystem goes far beyond reddit and developers. *Miners* didn't even communicate yet. Coinbase? Bitpay? The parts of the ecosystem I think matter the most aren't even on your radar.

Commented by /u/melllllll in /r/btc on August 6, 2020 13:20:49

They can! The situation here is two proposed consensus changes (forks), so we'd have two independent chains if they were both mined. If someone continued to mine the legacy chain, we'd have a third independent chain. If all the miners refused to upgrade and just kept mining the old chain, we'd just be skipping an upgrade and nothing would change. The issue is, where do the users go? If all the businesses upgrade to one chain, and a bunch of miners keep mining the legacy chain, their block rewards are now coins that aren't supported by the businesses and don't have much value. So there are economic factors that incentivize everyone to stay on the same chain, be it the old chain or one of the upgraded chains.

Commented by /u/melllllll in /r/btc on August 6, 2020 13:17:44

The BCHN team is going to have to implement a form of governance if they're going to be able to make decisions reliably.

Commented by /u/melllllll in /r/btc on August 6, 2020 13:11:12

I want to know who chooses the specified address. If it's hard-coded, it's a major security issue, I think. Do you know? It's come to two weird choices, but they have the same DAA so I'm pretty excited that the oscillations are going to be fixed. I'll probably just trust the miners to choose because they're the ones that would pay the 8%: >This allows Bitcoin ABC to make this much needed improvement while miners who may prefer other rules are free to choose a viable, alternate implementation.

Commented by /u/melllllll in /r/btc on August 6, 2020 13:05:49

\>where he at last forcibly “tells us” *what’s going to happen whether we like it or not*. \>This allows Bitcoin ABC to make this much needed improvement while miners who may prefer other rules are free to choose a viable, alternate implementation.

Commented by /u/melllllll in /r/btc on August 6, 2020 12:55:39

I think they should elect someone to be captain for efficiency's sake.

Commented by /u/melllllll in /r/btc on August 6, 2020 12:47:41

It's adjustable by the end-user, the thing that gets raised in the announcements is the *default* block size cap. Even without the default size raised, the miners could coordinate to raise the hard cap today with no software update.

Commented by /u/melllllll in /r/btc on August 6, 2020 12:44:34

We're replacing a dictatorial lead maintainer so we're going to socialize the maintainer role amongst reddit users. Also we're in charge of what protocol updates go through. So... You're lookin' at the face right here, good sir. Just go to that "Hot" tab and see what we're up to.

Commented by /u/melllllll in /r/btc on August 6, 2020 03:01:39

I think you maybe misunderstood everything. Start here: [whitepaper]( Spend a couple hours reading that for a good foundation and then ask questions here.

Commented by /u/melllllll in /r/btc on August 6, 2020 02:47:17

We're not in another no-change-breaks-bitcoin situation like the 1MB block size cap, so developers don't actually have anything held hostage. Developers can BLOCK a change, but they can't force a change through because the miners would simply not upgrade. Don't worry, there's no chance of absolute failure. This is just a weird situation that has to play out, and then we'll get going again, even if the damage causes a delay.

Commented by /u/melllllll in /r/btc on August 6, 2020 02:40:51

\-Not yet, pools need to announce what they're doing and it could take months \-ABC is connected with Bitmain, which is connected with CoinEx. \-Exchanges decide what gets what ticker independently. It sometimes takes a while for enough of them to get on the same page that the stragglers are actually incentivized to correct their ticker (After the BSV split, Bitfinex listed the ABC chain as "BAB" for months but eventually caved and updated it to "BCH," Binance listed it as BCHABC for months as well before updating) \-Maybe! Everyone was super rekt by the BSV/BCH split because there were threats of 51% attacks that caused exchanges to freeze the winning chain for weeks, and no replay protection which caused a lot of trouble for users and exchanges. In theory a split could be free from such disruption and damage if it had replay protection and nobody threatened to sabotage the competing chain. \-Haha I hadn't thought of this. People are pretty used to splits by now so it probably won't be a big issue. Whichever one loses the ticker has to start all over, which would not be worth it over this particular issue (so hopefully no split).

Commented by /u/melllllll in /r/btc on August 6, 2020 02:25:42

Haha, at least you're realistic :)

Commented by /u/melllllll in /r/btc on August 6, 2020 02:09:28

I hope they all decide behind closed doors that they'll go the same way. Divide-and-conquer for sure. People with actual businesses are smarter than the reddit mob, right?

Commented by /u/melllllll in /r/btc on August 6, 2020 01:58:45

And if they can't? Another split?

Commented by /u/melllllll in /r/btc on August 6, 2020 01:52:21

Aaaand block. Gotta do some quality control, sry :)

Commented by /u/melllllll in /r/btc on August 6, 2020 01:50:24

It's not the miners so much as the businesses. If there are two hard fork upgrades put out, then everybody (including the miners) waits for Coinbase, BitPay, etc to announce which implementation they're going to dedicate their infrastructure to. Since anything is better than a split, hopefully they all choose one path (DAA#1, DAA#2, no upgrade) and we won't have a split.

Commented by /u/melllllll in /r/btc on August 6, 2020 01:46:58

Then why even reply though?

Commented by /u/melllllll in /r/btc on August 6, 2020 01:39:13

Informative and insightful as usual, Remora\_101.

Commented by /u/melllllll in /r/btc on August 6, 2020 01:36:49

It's a nice thought, but I just saw both sides completely fail to cooperate over a non-emergency issue.

Commented by /u/melllllll in /r/btc on August 6, 2020 01:32:43

Rejecting dictators and replacing with... ...... ?

Commented by /u/melllllll in /r/btc on August 6, 2020 01:30:19

I think that's just the saboteurs fanning the flames. We'll see what the people that matter think, believe it or not reddit doesn't determine the outcome.

Commented by /u/melllllll in /r/btc on August 6, 2020 01:18:16

I actually think nearly the whole ecosystem (not saboteurs) wants no split, regardless of the path (DAA#1, DAA#2, no DAA fix).

Commented by /u/melllllll in /r/btc on August 5, 2020 20:51:55

The way to avoid a split was to not have a choice. This isn't the "choice not to split," this is one of the two "choices to split."

Commented by /u/melllllll in /r/btc on August 5, 2020 18:00:09

I can see that... The infrastructure (coinbase, exchanges, site...) increases utility. So utility may be the best way to predict value, and the infrastructure is a massive factor in utility.

Commented by /u/melllllll in /r/btc on August 5, 2020 17:17:22

But they're broken...

Commented by /u/melllllll in /r/btc on August 5, 2020 17:11:11

BCH would be a hostage in a sense that it couldn't have consensus changes, but it would be immune to people trying to split it.

Commented by /u/melllllll in /r/btc on August 5, 2020 14:35:12

I don't disagree. But now a second party is making the opposite decision without "respecting" the part of the ecosystem on the other side, so it's not like one is "right" and the other is "wrong" it's just that now we are split. The only no-split path is no consensus changes. I'd actually pick that path right now, the BCH protocol is good enough and we might not survive this.

Commented by /u/melllllll in /r/btc on August 5, 2020 14:31:48

>I'm a bit less certain if it's possible to create value without any work, though. I'm sure it's possible, probably called luck (like finding a gold nugget on the beach). If by infrastructure you meant businesses, then I could see what you mean. I would rephrase it in terms of utility, though.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:29:38

I'd literally rather just take what we have today and never again do consensus changes than split.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:25:22

Infrastructure includes businesses, they are the next in line to choose split or no-split. Edit: wait hashrate is next. Then infrastructure (which means businesses to me).

Commented by /u/melllllll in /r/btc on August 5, 2020 13:22:29

Cannot agree more. If I only had the information "which chain has the most fighting on it?" I could probably find the one that has the best shot at being sound, global money.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:19:38

You choose split over postponement, is all. I would choose oscillations over split.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:16:50

>If that value is derived from the work done to build and maintain this infrastructure This sounds like the Labor Theory of Value, I think something else determines the market price of coins.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:15:04

Infrastructure to me would be Coinbase, BitPay, (the website not the pool), exchanges... The businesses. They'll probably weigh in a week before November 15, just like last time, if there are two incompatible hard fork upgrades competing. I just hope Jihan and Roger are on the same chain, or else we're pretty much fucked. That there are two incompatible hard fork upgrades instead of an upgrade and a no-change implementation shows that people wanting this prioritize their upgrade over no-split, and also over democratic consensus because it hasn't been reached (if that were required no-change would be the logical path.) Sucks to split, but people do as they do.

Commented by /u/melllllll in /r/btc on August 5, 2020 13:11:42

I'm not making a judgement call of whether it's worth it or not compared to a different, hypothetical path that we may not even have as a choice. I'm figuring out an economic benefit of reducing inflation to make sense of why the miners would want this, because somebody in power wants this (not just ABC devs) or it wouldn't be proposed. The actual paths we have to choose between will unfold in the next few weeks or months. First we'll see which ones will be mined (hopefully just one and that's the end of it). If there's more than one, we'll then see which path businesses dedicate their infrastructure to (hopefully it's overwhelmingly one chain). If a second chain remains viable, holders will weigh in by trading their coins.

Commented by /u/melllllll in /r/btc on August 5, 2020 12:50:06

Next Time on Dev Meeting... Did Amaury Really have Technical Difficulties? Will Anthony Ever Forgive John? Is a Split *Inevitable*??

Commented by /u/melllllll in /r/btc on August 5, 2020 12:35:37