Gold collapsing. Bitcoin UP.

[freetrader]

@satoshis_sockpuppet : Fair enough. Though I think ABC does try to respect the schedule, however they have neglected criticism of the schedule without consequence, and when it comes to consensus rules I think you're right that the other implementations are in a catch-up situation.

Does this merit the view of ABC as de facto dictator?

I see the problem more as the existence of a clear majority implementation used by miners.
In that sense, it has somewhat degenerated to a state that's again not optimal.
But as long as a majority can form within miner use, some implementation will always get this label.
The problem would also not be solved if suddenly 80% of miners switch to using BU.
It would simply fall on BU to then "dictate", if you wish to view it that way (and others would).

IMO it would be more healthy if no implementation had such a clear mining (and general use) majority.
This would require more discussion and negotiation to implement consensus changes. One might see this as a good thing (I do) or a bad thing - I'm not claiming my opinion on this is necessarily "the right one".

I fail to see why we need different implementations in this situation.

For the same reason multiple implementations were a good idea even in the days of Core.
We have seen each of the implementations (including ABC) get hit by serious bugs. It happens.
Where there is diversity of implementations, the impact of such bugs can be constrained a bit.
This is how BU is also providing security to the BSV chain, by supporting it as an implementation. I'd wager it's why SV supporters are petitioning for BU to stay with them (by supporting their scaling test network).

 

[Zarathustra]

This is how a funded, non-commercial organization like Bitcoin Unlimited works.

There is no greedy boss on top.

I want that greed back. The greed all BU members have.

Make my computer money worth more.

@theZerg was last seen: Jan 31 2019

 

[Christoph Bergmann]

this is crux of the disagreement.

on the one hand these guys say we don't need to remove (or increase) the limit now because the demand isn't there; "we'll do it when it's time" (years from now). but at the same time they warn that we need to insert all these scaling optimizations now before the protocol ossifies. so, if the protocol is going to ossify, how the heck are they going to get a blocksize increase through "years from now" ?

Yeah, this was exactly how I felt when ABC wanted ctor but refused to lift the limit: we are back in core mindset
[doublepost=1552993994][/doublepost]

I think it will be hard for BU to be ready for 2048 MB blocks in November. But, it's possible.

I want to see @Peter R, @theZerg, @sickpig & Co kick nChain ass by scaling BU better than the 2 intercompeting SV-nodes.

But are we up for it? Or is the focus to negotiate with @deadalnix on protocol changes?

Please take a step back and see the value of a stable protocol and real demonstration of current capacity from an external business' perspective.

I can't say how much I agree. Let's write a buip.
[doublepost=1552994055][/doublepost]On another note...

Lazyfox.io is a awesome platform, and it works amazingly well with badger wallet.

 

[cypherdoc]

watch out :

"This is not meant to put down the MuSig designers by the way. I feel that the new protocol is going to turn out to be strongly secure, but I'm not a cryptographic expert by any means. But we need to be Really Sure because a 0-day exploit in it would be disastrous."

 

[sickpig]

I think it will be hard for BU to be ready for 2048 MB blocks in November. But, it's possible.

I want to see @Peter R, @theZerg, @sickpig & Co kick nChain ass by scaling BU better than the 2 intercompeting SV-nodes.

I'd say... why not. It would great to put some stress on Bu code base.

Just looked at https://bitcoinscaling.io/

I'm going to set up a node and see how things will go in the next few days.

@shadders a part from the different network magic bytes there's and setting up proper set of seeders, are there any other code changes?

 

[Mengerian]

@cypherdoc BU has always been listed on that page. I guess you are asking because of ABC's emergency checkpointing change. I expected that would be regularised via this https://github.com/bitcoincashorg/b...5ebc7f0d78e6c9cb/spec/20190515-may-upgrade.md
but it appears to be missing. So yeah, I'm not sure why there is a BCH hard-fork schedule when consensus changes can be rolled out anytime on an ad-hoc basis.

The 10-block finalization scheme is not really the same thing as "checkpointing". Checkpointing implies that developers add particular block hashes into the code as checkpoints. The finalization scheme is different in that the software treats blocks as "final" depending on its observation of live network conditions.

Tyler Smith has a good article about this: https://medium.com/@tcrypt/auto-finality-in-nakamoto-consensus-e2254f06ca97

I would also say that it is not really a consensus change, in that way that the other items in the specification are. It doesn't change what blocks are considered valid or non-valid, it just determines which chain the node will follow in the case of multiple valid chains. Nodes can adjust the finalization "depth", so it's possible for them to change the default if desired.

In this way it is conceptually similar to BU's "Acceptance Depth" code. This is also a system that allows nodes to choose among competing valid chains based on something other than pure chainwork. So I don't see why, for the purposes of the specification, ABC's finalization scheme should be treated any differently than BU's Acceptance Depth.

That being said, if someone thinks these things should be added to the specification, they should make a proposal and/or make a pull request. And if there are technical problems with finalization scheme, or reasons to change it, they should be looked at and considered seriously. I personally think that it would be good to replace the finalization system with something better in the future.

 

[theZerg]

Clemens Lee was the first to independently prove this, but others have agreed since. Bitcoin is Turing complete, as it is. Once the other original, disabled, opcodes have fully been restored (pers comm) the scripting language will be better understood.

Clemens' construction is not Turing complete at all -- its not even a computer. It simply creates a data stream that can only be changed (spent) via multisig and then relies on the multi-sig parties to independently run the code on their actual turing machines (aka computers). You can see the multisig formulation right in his presentation. For a detailed analysis read my work here: https://medium.com/@g.andrew.stone/why-bitcoin-cash-script-is-nearly-useless-and-what-to-do-about-it-b47adbfeceec

I'm sympathetic to the idea that someday the base protocol will be "done" (except for fixing possible future crypto exploits). But the reality today is that wishful thinking does not make it so.

Multisig is the basis for the nChain technologies I've read in smart contracts and tokens (which is not nearly all nChain tech so please don't "rebut" me by pointing out 1 piece of tech that does not use multisig). But the only real blockchain technology in there is the multisig in that it is an escrow without an escrow agent. The blockchain removes the need to trust a 3rd party agent. But when it comes right down to it, 2 people have put some money in a joint escrow and those 2 people ultimately will argue about how it comes out.

Any pre-agreement about the future disbursement of those funds (for example, as specified by a "smart" contract stored in OP_RETURN) is no different than any traditional agreement by 2 people -- ultimately continually relying on the goodwill of those people. So when goodwill breaks down, the final disbursement ratio may come down to who needs the money more, or who has the best lawyers. These are neither innovative nor blockchain technologies.

On the other hand, with blockchain technologies, the blockchain actually does the enforcement. If you don't like how the smart contract executed, you can't stop the disbursement of the funds. Yes, you can certainly talk to me or even sue me afterwards to claim the gains awarded to me by the blockchain were "wrong", but that is very different because the onus is on you to pursue extra-blockchain social methods while I have ownership of the award.

You can argue that L2 technologies over multisig are enough (I would not, because blockchain tech is most useful where the path to a social resolution is unclear -- like across jurisdictions). You can even argue that they are better from a statist perspective (they allow businesses full control over issued tokens, and give participants override power with buggy smart contracts). But you can't argue that they are equivalent to similar blockchain technologies, or follow the philosophy of the "native" censorship-resistant, P2P, pseudo-anonymous, unstoppable, crypto be it BSV, BCH or BTC.

It dismays me that this is not understood in this forum, among real crypto veterans here.

 

[freetrader]

In this way it is conceptually similar to BU's "Acceptance Depth" code.

This is actually an really good point that I've not seen anyone make before.

I would however strongly take the viewpoint that both are consensus mechanisms since they ultimately determine what chain tip your node follows. Whether it's configurable isn't really decisive imho - e.g. there are parameters for block sizes too and I don't think anyone would argue that those are not critical to consensus.

 

[cypherblock]

This is all new to me, as i'm sure it is with almost everyone else,

News to you that Clemens did not prove anything? If you watch his video (I think the only evidence he's provided) you will either come away not understanding what the fuck he's talking about (which is understandable, cause he doesn't do a good job of explaining), or realizing that while he may have invented something interesting and perhaps complex it does not prove bitcoin is turing complete as it involves other parties and so on.

You can of course write software (using a turing complete language or perhaps something less that turing complete) that interacts with the bitcoin blockchain, and then as a system those things can be said to be turing complete. Anyway to me the whole thing is a moot point. If you've invented something cool, and useful, then put it to use. Make it public or not. At minimum I would expect a simple example ("here's how to do the square root of a number", "here's how to solve tic tac toe", etc) to be provided by anyone wishing to be taken seriously. I do think Clemens is a smart guy and may have some cool stuff. I just haven't seen it yet.

 

[solex]

In this way it is conceptually similar to BU's "Acceptance Depth" code. This is also a system that allows nodes to choose among competing valid chains based on something other than pure chainwork. So I don't see why, for the purposes of the specification, ABC's finalization scheme should be treated any differently than BU's Acceptance Depth.

@Mengerian I appreciate your explanation, and the nuance of finalization, however, comparing with Acceptance Depth (AD) alone is akin to the comparing proverbial apples and oranges. The point of AD is a mechanism to ensure re-convergence when nodes use the Excessive Block Size. Conceptually, the EB/AD removes the max block limit from the protocol to the transport layer. The AD does not function by itself.

Further, when BU was battling Core for BTC mining share, we were being somewhat brutal to all the Core nodes, prepared to force them all off the Bitcoin BTC network in order to achieve onchain scaling.

In hindsight, maybe we should have released a separate Core version with a block limit equal to the default EB, i.e. a minimal change, so that all the forked off users had an alternative which did not have other BU changes. Anyway, introducing EB/AD was itself a consensus change in order to remove the max block limit from consensus.

As @freetrader says, any change which creates potential disagreement about the chaintip looks like a consensus change. Maybe we have to agree to disagree.

 

[Zarathustra]

You can of course write software (using a turing complete language or perhaps something less that turing complete) that interacts with the bitcoin blockchain, and then as a system those things can be said to be turing complete.

"Perhaps" ?

If you'veinvented something cool, and useful, then put it to use

This is from unwriter. Is it cool? is it useful? is it turing complete?

https://www.reddit.com/r/btc/comments/9mfatw/hi_today_im_releasing_bitquery_a_turing_complete/

 

[cypherdoc]

In hindsight, maybe we should have released a separate Core version with a block limit equal to the default EB, i.e. a minimal change, so that all the forked off users had an alternative which did not have other BU changes.

yep.16mb default limit iirc?

 

[satoshis_sockpuppet]

This would require more discussion and negotiation to implement consensus changes. One might see this as a good thing (I do) or a bad thing - I'm not claiming my opinion on this is necessarily "the right one".

I really really loved to see f**ing miner voting on BCH. But this is sadly not going to happen.

For the same reason multiple implementations were a good idea even in the days of Core.

Will be hard to motivate developers to develop under such conditions.
When developers of implementation B have valid concerns about consensus changes the developers of the ruling implementation A are planning but aren't heard or taken serious in any way.. And then have to clean up the shit afterwards..

 

[Richy_T]

In hindsight, maybe we should have released a separate Core version with a block limit equal to the default EB, i.e. a minimal change, so that all the forked off users had an alternative which did not have other BU changes. Anyway, introducing EB/AD was itself a consensus change in order to remove the max block limit from consensus.

It would have been interesting as a datapoint but I think it would have ultimately made little difference. Core loyalists were core loyalists. I put a 2MB blocksize limit compiled version out there and there was no interest. Granted I didn't promote it heavily but I know some interest would have coalesced around it if anyone cared but it just didn't seem to be a direction people were interested in.

 

[Norway]

 

[theZerg]

I think Peter R's dialog with CSW about selfish mining is well known, he was one of the first people to call CSW out, and additionally discovered the plagarisms

I have also been critical, although I refrain from making personal comments and focus on the technology so my comments rarely have the sort of emotional nastiness that drives clicks in this twitterized world. Here are some of writings:

Destroying nChain's hash chain tokenization proposal:
https://medium.com/@g.andrew.stone/hash-chain-tokenization-criticism-382c2f4fe0fb

Showing that claims of "Turing decider" or turing completeness are wrong and/or irrelevant:
https://medium.com/@g.andrew.stone/why-bitcoin-cash-script-is-nearly-useless-and-what-to-do-about-it-b47adbfeceec

BSV supporters "just loved" /s this post and so it got a lot of flak, because it poked holes in Ryan Charles's crazy idea that since you could (in theory) do DSV in a million instructions we shouldn't include it:
https://medium.com/@g.andrew.stone/forkless-inclusion-of-functions-loops-and-new-opcodes-in-bitcoin-script-6bd1155a9f5a

Recently on reddit I was quoted in one of those lists of all CSW's bad ideas for destroying his claim that we are running out of opcode space. And a few posts above this one, you can read me criticizing BSV's copying Core's idea of locking down the protocol. I know of no technology that has survived such a lockdown -- crypto is not gold.

I haven't look into it much but I personally think that the lawsuit is completely inappropriate, is intended as an intimidation technique, and call on whoever is behind it to stop. If you won't stop out of decency, then do so for the good of the BSV coin, since I believe your behavior will push away developers and investors.

Perhaps not coincidentally, another reasonably well known member of the ABC community has come to me in the last few days with a similar "if you are not 100% with us you are against us" mentality. And there have been others in the last few months. As I post here: https://medium.com/@g.andrew.stone/bitcoin-cash-and-bitcoin-sv-stop-the-self-destruction-386ea3e09b6e, it will be very unfortunate for BCH in the medium to long term if it remains closed to ideas coming from outside the core ABC group and instead embraces an us-vs-the-world mentality.

I think that some people may think that I am indecisive because I've steered BU to offer a compromise. But I think that you should take your schoolyard tribalism and shove it up your asses. There is a world to introduce sound money to and yet all you keyboard warriors do is sit around and fight each other.

 

[Norway]

Looks like more people will apply for BU membership:

 

[Christoph Bergmann]

Now, when I warmed up to like bch again...

It's his good reason to lay down membership. It's not so nice to use it to push bu away from bsv.

@theZerg you don't have to excuse yourself for being too friendly to csw or something. You made a proposal to prevent the split, but ABC blushed it into anti csw warmanship. Things would be much nicer when abc listened to bu.

 

[cypherblock]

This is from unwriter. Is it cool? is it useful? is it turing complete?

Seems cool. But has little to do with claims by Clemens Ley that bitcoin is turing complete.

 

[Zarathustra]

"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime."