Gold collapsing. Bitcoin UP.

[Zarathustra]

On that topic: Is this true?

Zero comments from the BU senior members. Not good.

 

[lunar]

Looks like for the time being at least, Bitcoin Cash has a benevolent dictator.

I guess we'll see come Nov 15th if there's enough hash to back up these strong words?
1-8

 

[imaginary_username]

The primary hurdle even after years of debate, is still the f'in blocksize.

Lack of usecases ain't got nothing to do with blocksize limit. Fill up 1MB and we'll talk about lifting 32MB.

 

[Norway]

Lack of usecases ain't got nothing to do with blocksize limit. Fill up 1MB and we'll talk about lifting 32MB.

Sounds like you want to be part of a central planning committee, setting quotas for blockspace, @imaginary_username.

Why do you want this power so bad?

 

[imaginary_username]

Why do you assume I have any power or will get any?

 

[Norway]

I didn't.

 

[freetrader]

No-one has yet submitted a 10TB default proposal to Bitcoin SV ?

https://github.com/bitcoin-sv/bitcoin-sv/issues?q=is:issue+

Why is that?

 

[Norway]

@freetrader
You tell me.

 

[freetrader]

As initiator of the proposal, I was hoping you'll tell us.

I'm going to assume for now that you prefer BU to SV and wanted only BU to get the benefit of this change.

Is BU working with nChain on bringing bignum back?

I think BU should not offer to work with nChain on this unless

a) it results in BU earning significant money for such outsourced development work
AND
b) it is done under terms approved by the BU membership

Just today nChain's Chief Scientist threatened BU with a patent he allegedly holds.

 

[Norway]

@freetrader
I asked about bignum because I know SV have reached out to BU on this issue. Bignum would make DSV more or less obsolete and is a more general approach than custom OP codes.

I strongly disagree that developers should ask the BU membership for permission to develop anything.

It feels like some people will take any position, as long as it's opposing nChain. This is cult behavior.

 

[freetrader]

As a BU member, and your question specifically asked about whether BU organization is going to work with nChain, I'm all for giving them moral support in bringing bignum back.

Just to check: you also support the bignum versions of the new opcodes?

 

[AdrianX]

The primary hurdle even after years of debate, is still the f'in blocksize

Lack of usecases ain't got nothing to do with blocksize limit. Fill up 1MB and we'll talk about lifting 32MB.

@imaginary_username I'm concerned you think you are part of the "we" who is in control of enforcing the 32MB limit.

In theory, the transaction limit should not be part of the consensus layer. The fact it is, is a problem. Your attitude "change it when needed." reminds me of the attitude to the 1MB limit. The truth is 93% of the hashrate out there will move to BCH if it is the most profitable coin to mine.

They are an overwhelming majority and have expressed a will to not change the limit when needed. A cartel enforcing a limit can maintain the limit and prevent increasing it. (just replay events in bitcoin from 2013-2017)

If your attitude was universally applied, need being a motivation for consideration, let me FT;FU

Lack of usecases demand ain't got nothing to do with blocksize limit changing consensus rules for CTOR. Fill up 1MB 10MB and we'll talk about lifting 32MB adding CTOR.

 

[AdrianX]

I am not condoning his actions or saying he should or shouldn't act the way he did, but Amaury is a long-time BU member and do we really want to go down the rabbit-hole of accusing him of attempting to intentionally sabotage the client?

Not that I think any action need be taken, But some prominent ABC developers have admitted to doing just that, no need to accuse them of attempting to intentionally sabotage BU.

 

[NewLiberty]

Let's use BASIC to construct a program that clearly halts, but is infinite.

Is it infinite? Unless the computer it is stored upon, and running it, is infinite I would say not.
Perhaps such an infinite computer can be imagined, but it is not a thing.

 

[AdrianX]

Then, someone comes along and says "This whole thing is a bad idea, but to point out how dumb this is, I'm voting for it".

The thing is, is it a bad idea?, sure it is bad for ABC as ABC can't do parallel block validation, and thus, ABC is susceptible to a poison block attack, but I don't find all the reasons to limit blocksize are justified.

 

[AdrianX]

Just today nChain's Chief Scientist threatened BU with a patent he allegedly holds.

@freetrader that's not a threat, that's a compliment from someone with a bruised ego.

 

[NewLiberty]

As initiator of the proposal, I was hoping you'll tell us.

Just today nChain's Chief Scientist threatened BU with a patent he allegedly holds.

Don't see such a patent being enforceable. Can't patent "bitcoin script compiler" and cover everything. Could copywrite, but there are many ways to do this, and easy to navigate around such a patent even if it were enforceable.

 

[Mengerian]

The point is, anyway you look at, we need to get the Tx volume way up, ASAP. Halvings are in 11/2 & 51/2 years. If we're not getting to GB volume by then, the whole project starts to look economically shakey.

It's essential we onboard some major company backends before then.

Yeah, I agree with that. I think pretty much everyone in Bitcoin Cash agrees with that. That's not new information, it's what we are all working towards. The problem is that letting nChain take control of the protocol makes it less likely this will happen.

The primary hurdle even after years of debate, is still the f'in blocksize. How can this be?

I perceive that differently. Doesn't seem to me like the block size limit is what's holding back adoption. ABC and BU are working in removing technical scaling bottlenecks, Bitcoin.com and others working on spreading adoption, and many groups working on building a developer ecosystem (Bitbox, BitDB, Memo, etc.). To me these seem like the things that energy should be focused on.

 

[cypherdoc]

@Mengerian

>The problem is that letting nChain take control of the protocol makes it less likely this will happen.

isn't that the same attitude Adam Back gave in his infamous "coup" argument? as in, you in fact believe ABC has control to protect?

 

[NewLiberty]

Adding CTOR, I have no problem with doing this.
It is the subtracting of other ordering methods where it becomes a problem.

CTOR is better for many blocks. However if it is not the best for all and also for all conceivable evolutions into the future, then it has no business being a consensus rule. If it is better, use it, if not, use what is better. Doing it this way assumes a consensus which is not in evidence, as well as being a myopic short sighted design choice.

The way it is implemented in ABC is as a soft fork sneaking in to a hard fork. As implemented in BU, (as an option), is immensely better. SV doesn't implement it at all.