Gold collapsing. Bitcoin UP.

[shadders]

Hi Cypherdoc… Interesting set of questions.

Firstly we’ve been very vocal about the fact that the original Bitcoin consensus protocol is patent free and will remain so. It’s all been in the public domain for years and so it’s prior art making that a moot point. We’ve also been very vocal about the fact that we intend to deliver software that restores the original Bitcoin protocol and then lock that protocol down in our software implementation. That brings us perfectly into alignment with the set of prior art that was made public 10 years ago. So unless you think we are planning a last second diversion into some bespoke variant of proof of stake or some other nonsense I think this question should be settled by decades of patent case law.

So IF we were to go completely off-the-wall batshit crazy and try to modify the original Bitcoin protocol (the precise opposite of what we’ve put everything on the line to avoid) what is the absolute worst that could happen assuming we were as evil as you can possibly imagine? Well we’ve established the original Bitcoin protocol is patent free. We know the Bitcoin client software up until today is licensed under the MIT open source license, and it’s fairly close to the targeted consensus protocol already. So even if we made the license proprietary tomorrow you could fork today’s version, rewrite backports of any consensus changes we’d made subsequently and be up and running pretty quickly. When you’ve got reference code it’s really not hard to rewrite around licensing. That’s the absolute worst case and it makes some pretty incredible assumptions to get to that case.

As to licensing… I’m not opposed to BSV-only licensing of the client software. What matters though is how you define BSV. It’s clear to me that with a blockchain you can only reliably define it with respect to history (e.g. longest chain that includes block x, post nov 15, 2018), not with respect to the future. There are only two ways I can see to define a license today that specifies future forks of persistent splits: 1) define it by a complete set of protocol rules in which case it’s clear to everyone well in advance and would be tediously long, or 2) insert a discretionary clause i.e. ‘person x decides’, which I would find utterly unacceptable. So any BSV license would be open to all use on Bitcoin SV and to future hard forks or at least it would be very clearly defined what the properties are of a fork it would apply to and that would also preclude the possibility of even us making changes like 63m coin limit. The solution to avoiding future chainsplits is not a legal one, it’s mass proliferation of SPV (real SPV not the variants we have now) and proof of work. If a license were to be devised that made that not the case then the opposing faction could simply fork the code that existed the day before the license came into effect and compete from that point. If necessary taking the time to prep the code for the fork attempt before beginning their campaign with miners.

At the end of the day, anyone can change a license anytime they want and it takes effect from that day forward. I could fork BU or Core code right now and put a proprietary license on all new code I added to it. So no assurance I give you or anyone else will be good enough. People like Freetrader will always assume I am lying. If we do go batshit crazy and raise the coin limit to 63m and there is no one to replace us with an alternative client then that is a failure of the market to perceive the value of keeping the original Bitcoin protocol stable and respond with someone willing to take a capital risk on providing an alternative. If that fails to happen then bitcoin will die. You might have noticed that someone stepped up, committed millions and made this happen once before though. If a defender of the original Bitcoin protocol fails to emerge, I would consider it a complete and utter failure on my part to help build a viable Bitcoin ecosystem. I’m sure there would be many that would feel the same.

 

[lunar]

If you like to think big, and examine what the future might be like, with an unlimited BSV. $brendan has some amazing and well thought out predictions up to 2065

*skipped the first few mins of streaming issues.

 

[majamalu]

BCH has a chance at beating BTC because for anyone with a brain it's obvious that it works and will continue to work much better than BTC.

What if BCH eventually becomes the new Schelling point? Let's say that it's true that ABC is making big mistakes; are those mistakes big enough to be noted by the users and, even if they are aware of them, to make them leave in droves towards BSV?

I think that would be a very different scenario than BTC versus BCH. Overcoming the BTC Schelling point is not easy, but we are being actively helped by the Core devs and their minions.

 

[Zarathustra]

> What if BCH eventually becomes the new Schelling point? Let's say that it's true that ABC is making big mistakes; are those mistakes big enough to be noted by the users and, even if they are aware of them, to make them leave in droves towards BSV?

But Bitcoin is not one user one vote. Bitcoin is about selling/buying blockspace, one bit one vote. Bitcoin. A user Nasdaq would produce more votes than a million UASF users combined. ABC's mistake could already be big enough.

https://coin.dance/blocks/size

 

[davewantsmoore]

as long as we're trying to hold people accountable around here, how about holding the small blockists, like @freetrader & @jtoomim et al, who told us BSV could never accomplish all the things they're accomplishing everyday now;

Hold them accountable??? This is the problem with "the community". They listen to people say things they don't understand, and then decide if it's "the truth" or not... it's one giant circle jerk.

Those people you're calling out, are free to talk whatever rubbish they want. Caveat emptor.
[doublepost=1554726557][/doublepost]

What if BCH eventually becomes the new Schelling point? Let's say that it's true that ABC is making big mistakes; are those mistakes big enough to be noted by the users and, even if they are aware of them, to make them leave in droves towards BSV?

No. The "users" (the real users) will never notice these things.

Do you notice there's a problem with Ethernet, or HTTP?..... You only notice when the product/services built on top of these things don't work the way you want them to (ie. they're deficient compared to something else you could use).

 

[freetrader]

 

[bitsko]

CTOR reads like one of those devvy bitcoin core things like schnoor (oh wait lol) or the handful of other things that are impressive to the developer ingroup with no bearing whatsoever on the end user(or lack thereof)

 

[sgbett]

I do have some sympathy for the devs in that regard, like none of my customers care about a bunch of stuff I work on day to day, but if I didn't do that stuff, then stuff they do care about wouldn't work half as well, or even at all.

The challenge is, as a dev, identifying the important things that they don't care about vs the things they don't care about that *seem* important to you (or more likely, are more interesting to work on - that's the thing that gets you!).

I don't think (and I speak as one) devs are always as laser focused on the business case (economic incentives!) for prioritising one thing over another.

 

[Christoph Bergmann]

BCH has a chance at beating BTC because for anyone with a brain it's obvious that it works and will continue to work much better than BTC.

What if BCH eventually becomes the new Schelling point? Let's say that it's true that ABC is making big mistakes; are those mistakes big enough to be noted by the users and, even if they are aware of them, to make them leave in droves towards BSV?

I think that would be a very different scenario than BTC versus BCH. Overcoming the BTC Schelling point is not easy, but we are being actively helped by the Core devs and their minions.

Yes, it might happen that bch becomes the new Schelling point, but it requires a massive effort in creating an absolutely convincing usability.

For bsv, it seems like the better strategy to not focus on competing with bch, but on creating something new... Which is what they already do.
[doublepost=1554728384][/doublepost]I will launch a bitcoin / crypto marketplace and listing every article I can get. If you have books, merchandise articles or anything else, get in contact with me.

 

[freetrader]

They listen to people say things they don't understand

I'm glad people are at least asking questions.


For your answers, look here (August 2017 BCH HF specification):

https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md

The answer to your question lies primarily in the consensus changes introduced by REQ-3, REQ-5, REQ-6-2, REQ-6-3 and REQ-7.

 

[Richy_T]

I think that would be a very different scenario than BTC versus BCH. Overcoming the BTC Schelling point is not easy, but we are being actively helped by the Core devs and their minions.

This is true. But my concern is that the constant deving on BCH could keep people away due to uncertainty. It's yet to be seen if this will persist and continue to be an issue or if this is just a short burst of activity and things will calm down. There's always the (small) chance that BTC will gain real bigger blocks too, of course.

In my mind, it should have been raise the block size limit and focus on re-establishing the growth that was being given the finger by BTC with a road map for protocol improvements over a much longer time period. It would suffer from bike-shedding, of course but that's better than what we currently have.
[doublepost=1554748108][/doublepost]I like BSV for this (ignoring my issues with certain characters for a moment) but they do have an uphill battle to reach the tipping point and users are not going to flock at this stage. It's more BCH's to lose than BSV's to win at this point.

 

[79b79aa8]

. . . unless the first wave of users / use cases is different from what many of us BTC-BCH early adopters have assumed.

 

[Zarathustra]

Good to know.

 

[shilch]

The answer to your question lies primarily in the consensus changes introduced by REQ-3, REQ-5, REQ-6-2, REQ-6-3 and REQ-7.

I don't get why the transactions have been restricted to 1MB with the hardfork (in the Core client they are unlimited in size though limited by block size). Not that it's hard to increase but afaik this makes it difficult for BSV right now to increase the OP_RETURN limit (besides the 100kb non-standard rules) without forking away exchanges.
It was introduced with this commit "in order to prevent problems related to quadratic hashing", but didn't get reversed after introducing BIP143 sighash as mandatory.
[doublepost=1554761595][/doublepost]

I like BSV for this (ignoring my issues with certain characters for a moment) but they do have an uphill battle to reach the tipping point and users are not going to flock at this stage. It's more BCH's to lose than BSV's to win at this point.

Users and "community" doesn't really matter at this point, it doesn't magically increase transaction volume significantly. I like the approach of building business applications on BSV first in order to achieve a stream of income for the miners. It shifts the focus away from peer-to-peer cash (for now), but there isn't much value in scalable peer-to-peer cash right now (unfortunately).

 

[Richy_T]

. . . unless the first wave of users / use cases is different from what many of us BTC-BCH early adopters have assumed.

Could be. I don't see it as likely though as we have thousands of other coins with various properties and some things could have been implemented on BTC after a fashion. I think the primary driving factor is as money. Start chasing the secondary stuff too hard and you end up in LN territory, losing sight of what makes Bitc*ins special in the first place.

 

[freetrader]

I don't get why the transactions have been restricted to 1MB with the hardfork (in the Core client they are unlimited in size though limited by block size). Not that it's hard to increase but afaik this makes it difficult for BSV right now to increase the OP_RETURN limit (besides the 100kb non-standard rules) without forking away exchanges.
It was introduced with this commit "in order to prevent problems related to quadratic hashing", but didn't get reversed after introducing BIP143 sighash as mandatory.

The commit by @deadalnix which you linked already provides the rationale.
In Core they never needed to be limited specifically because the block size was capped at 1MB.

BSV should have thought about increasing that limit in November '18 then, if it matters to them for their OP_RETURN. AFAIK they were planning to do a hard fork anyway to increase their block size cap or something.
At some point they need to decide which is more important to them - exchange support or their filecoin-related protocol changes. I can't help with that.

 

[Richy_T]

Users and "community" doesn't really matter at this point, it doesn't magically increase transaction volume significantly.

I disagree. The value of crypto is in it being ubiquitous. If you want your apps to be usable, people have to be using your coin. Transaction volume itself is almost irrelevant (other than it be adequately provisioned).

 

[79b79aa8]

but there are many monetary transactions that are not done at point of sale. instead of alice pays bob for her coffee, the model may initially be XYZ corp. pays miners to [insert magic use case].

@Richy_T said:
> Could be. I don't see it as likely though as we have thousands of other coins with various properties and some things could have been implemented on BTC

yet nobody else is going for global, enterprise-level scale.

 

[Richy_T]

But why does corp XYZ hold that coin? Why does the miner want it? You can argue that they will want that coin to be able to do those transactions but that seems like putting the cart before the horse to me.
[doublepost=1554767389][/doublepost]Crypto needs adoption as cash because wealth has to flow in all directions. It can't just go corp->miner or you end up with just a proxy for filthy fiat and that's a weak position.

 

[79b79aa8]

obviously i don't have the magic use case, and if i did, i would not be saying much about it.

the natural case seemed to be settlement. to answer your two initial questions, financial institutions use the monetary vehicle because they can settle accounts, domestically and internationally, with minimal friction. miners mine it because it is profitable, as the liquidity involved in enormous.

this scenario didn't pan out at least partly because of (i) BTC's inability to scale (along the tx/s scale, but also in terms of a persistent immaturity of the mining market), and (ii) the financial world's initial, flawed assumption it could privatize the blockchain. at present it is not viable because BTC still can't scale and BCH/BSV/everyone else are insecure.

but perhaps a non-dominant bitcoin variant can get a foothold in, say, intracompany trade, enough to bring liquidity and security to levels where that original scenario does become viable.

this latter scenario is more likely than e.g. remittances. the normal receptor of a remittance is not equipped to deal with currency conversion, even in jurisdictions where it is legal.