Gold collapsing. Bitcoin UP.

[adamstgbit]

@Tomothy
patents probably shouldn't be considered when making changes to bitcoin itself.
i mean who cares if bitcoin infringes on a dozen patents, who are they going to go after? There is no bitcoin CEO, they going to try to tax usage on an individual basis all in different jurisdictions, lol good luck with that.

also, alot of these patents are probably not novel... the thing being patented probably sounds very complex, but for experts given these OP_CODE, trying to do XYZ OBVIOUSLY requires you to do XYZ.
in-which case the patent is meaningless.

even asicboots patent is just an empty threat, its never been tried in any court (afaik) and its probably been infringed on.

 

[freetrader]

Here's another one.

Blockchain-based Exchange With Tokenisation

"The invention provides a secure method for exchanging entities via a blockchain. The invention incorporates tokenisation techniques, and also techniques for embedding metadata in a redeem script of a blockchain transaction."

sounds like the sort of thing SBI would be interested in?

Sounds like the sort of thing any distributed exchange has already implemented.

 

[adamstgbit]

Because OP_MUL can overflow. It's that simple really, we didn't have time to deal with it. In the current script implementation, it is allowable for the result of an operator to overflow into a value that is too big to be considered a numeric. For example: <max positive numeric value> OP_1ADD. It's an oddity, you can see a reference to here on the line under the Arithmetic heading. Dealing with that "oddity" in a constructive manner is going to require some research and thought.

We do intend to prepare OP_MUL for the November upgrade.

handle it by simply letting it overflow? like C++ does it?
because the scripting lang is interpreted on different platforms which might overflow differently?
yup neat little problem

 

[Mengerian]

Just to add my two cents about the "OP_GROUP drama"

I think people should keep in mind that we are trying to move to a 6-month rolling upgrade cycle. The idea is to have scheduled upgrades (aka "hard forks"), so that they become routine and non-disruptive. Part of making it go smoothly is to have everything stabilize well in advance, with time for review, and for other parts of the ecosystem (wallets, exchanges, etc.) to be ready for any changes. It also means that whether a feature gets into a particular individual upgrade is not as important, since there will be other chances later.

I don't have strong opinions about OP_GROUP, but if some people raise issues with it, it makes sense to look at what was raised, see if it can be addressed somehow, see if other approaches would be better, etc. Then maybe in a few months, either OP_GROUP will be seen as the best option as-is, or it will be modified to address some of the objections, or another approach will be seen as better and implemented.

What shouldn't be done is to start politicizing it, where people form into factions that get entrenched in their positions. We may be going through some growing pains, but this isn't block-size-debate 2.0. We all share a compatible vision for the future, so it makes sense to keep working together, with all the frustrations that come with that.

 

[Christoph Bergmann]

what a two days. My mind has taken several spins, and I (hopefully) learned a lot.

1. If you are angry, reflect and research, and don't post. You risk not being proud on what you said and being unfair to other individuals. I thought I knew this, but ...

2. op_group has several extraordinary properties which should be discussed, explored, tested and maybe changed until it can be implemented. I like to see it implemented, as it seems a good way to create senseful token in Bitcoin, but my heart doesn't bleed for it.

3. The other op_codes ... it is very interesting, to expand the options they provide, even without a specific use case, and while it seems to be terrifying to implement the risks of several codes at once, these risks have been discussed and devs agree that they can be controlled. My opinion on it is not entirely clear, and I hope they will be subjects of some debates until May, in which both risks and concrete benefits will become more transparent.

4. fighting can be healthy. The result of last days are not just bad. The drama forced many people to voice their opinion, which helped to accumulate knowledge, and it gave insights into decision making processes, and hopefully it will help individuals (as me, see 1.) and the community to find better methods to discuss, decide and celebrate future hard forks. Also it is good to have this without censorship and the natural disagreement of decentralized teams. If Bitcoin Cash was a 1-man-show, like Litecoin, or not important, like whatever, there would be no fight. So it is a good signal ...

5. put public discussion before decision. I and seemingly some others have the impression that a decision was made and discussed / explained later in public. It would be better for everybody - especially the developers - when this goes the other way round. Something like a comment-period prior to the first step of the hard fork decision could be great.

I could go on and on, but have to stop here.

 

[adamstgbit]

@Christoph Bergmann

I couldn't agree more.
but I have a feeling the new op_codes will open a whole new world for bitcoin. its unclear exactly what can be done with them, like what could be the input for the OP_AND? can the inputs be some dynamic data like block height? ex. (( %BlockHeight% OP_OR 278312837 ) OP_EQUAL 278312837) returns true if the current block height is 278312837???

 

[Tom Zander]

I implemented BIP143 in classic. You are a compulsif liar, Tom.

What the fuck man...

You did some copying of code from Core that was needed for Flexible Transactions (in 2016), you did a crappy job (the unit tests didn't even pass) and missed maybe 33% of the changes needed. Copying code from Core is not implementing it. The fact that you missed almost half of the files shows you had no clue what you were actually doing and honestly would have been unable to write the code as new.

If you are honestly remembering it as you implementing an unrelated BIP many months later, that just leaves me speechless. The git logs can be consulted if you want. (54ef096 & c599bd2).

Calling me a compulsive lair is just... I don't even know what to say. Facts show I'm correct and you are misremembering.

 

[awemany]

@Mengerian: From all the criticisms against OP_GROUP, the one expressed by Mr. Fyookball has me the most convinced - that we change the principal operation mode of script evaluation. I wonder what @theZerg 's response to this point will be.

@hodl: Good points. You are conservative regarding changes for good reason.

So I guess I stick with my opinion that it is better to let it stew a bit longer. In general, I think we shouldn't be chasing the latest fads, be it ICO or anything, with BCH.

@lunar et al.: You are right that nChain/CSW is just one player in this space and they might well also not be the ones with the most aggressive patent policies. CSW is prominently and regularly featured on reddit and is pretty deliberate with trying to further and "protect" BCH from competition with these patents (at least that is how I read the tweet I quoted above) so this is why I took it as an opportunity to express my wariness on this issue.

I think there's much harm especially in SWPATs and I also think the level of non-obviousness required is so damn low that it truly becomes a minefield. "One click shopping"..

@Tom Zander , @deadalnix , @Christoph Bergmann : I did not keep up with the details on 'who said what' to have much of an opinion on your arguments. All I can say is that I don't particularly see problem with friction in this space per se. Helps to dispel the 'there's just one BCH and it is all centrally controlled' myth, I guess. But please try to keep it civil, though.

 

[Christoph Bergmann]

@Christoph Bergmann

I couldn't agree more.
but I have a feeling the new op_codes will open a whole new world for bitcoin. its unclear exactly what can be done with them, like what could be the input for the OP_AND? can the inputs be some dynamic data like block height? ex. (( %BlockHeight% OP_OR 278312837 ) OP_EQUAL 278312837) returns true if the current block height is 278312837???

Yes, it is exciting to have a lot new tools in the toolset of developers. I remember there was some note in the Ethereum whitepaper, that Bitcoin scripts can't interact with all things on the blockchain, so maybe inputs can't be dynamic data onchain (but I don't know ...)

Still, I'd love to have something concrete. Most things I heard by now are reinventing a better multisig, an onchain lottery and mocking blockstream by implementing their baby MAST first. When it comes to smart contracting in general, I doubt that Bitcoin Cash has chances to compete with Ethereum. Ethereum has hundreds of people playing with smart contracts for some years, and a smart contract language which is easier to use and more flexible in operations. So in my opinion it depends on if the new op_codes enable operations which make Bitcoin Cash a better P2P cash system. I hope we learn more until May.

I have two more numbers:

6. This vague advantage of those OP_Codes compared with the very concrete and demanded advantage of OP_Group triggered controvery.

7. Let's be happy that we do hard and not soft forks. If the devs decided to prickle the op_codes into anyonecanspends, as it is best practice on the Core chain, we would have had not so much to discuss.

 

[Zarathustra]

I applied these advice for ABC and it became quickly a major implementation. Now conclude. I'm sorry, I'm not insulting anyone here, just stating facts. Unpleasant ones, but facts nonetheless. I gave everything that was needed to be a huge success to BU and BU wouldn't take it. Now many BU member are complaining that ABC is easting their lunch. I don't even wanted to start ABC to begin with.

Bitcoin Cash (the lunch) is the result of a causal chain. Yes, without you there would be no Bitcoin Cash today and I applauded your punching power. But! Without Cypherdoc and many early and late adopters and contributors of his thread there would be no Bitcoin Cash either! Enjoy your lunch, you fully deserve it, but it will be destructive to declare those contributors as your enemies, liars, shit etc.

 

[bitsko]

5. put public discussion before decision. I and seemingly some others have the impression that a decision was made and discussed / explained later in public. It would be better for everybody - especially the developers - when this goes the other way round. Something like a comment-period prior to the first step of the hard fork decision could be great.

who is it that you are asking this of?

it's one thing to look to the bitcoin unlimited project to operate in a way that you, as a voting member want. such is the structure of this political and technological party.

it is entirely another to hold this expectation of the entire bitcoin ecosystem. I take it you don't hash much, it was clear you didn't engage the decision making process where it was occuring, you've acknowledged as such...

I don't want the wider ecosystem dictated by political opinionists. I want capital to fund innovation and implement innovation.

tldr; reasonable for BU, unreasonable for Bitcoin in general, perhaps antithetical to free market ideas.

 

[jessquit]

Hi everyone. New to this forum.

At the risk of dropping a turd into the punch bowl, can anyone clearly and succinctly help me understand what on Earth any opcode has to do with creating scalable peer-to-peer digital cash?

How does an opcode of any sort make it easier, faster, more secure, or cheaper to buy a coffee, a bag of weed, or 500 tonnes of wheat from a farmer?

 

[bitsko]

adoption

 

[Justus Ranvier]

I see a lot of people on Twitter and Reddit pointing out why switching it the proof of work algorithm would backfire on BTC.

Has no one ever heard of "never interrupt your enemy when he is making a mistake?"

 

[bitsko]

I wish cobra was relevant to the decision-makers in core

 

[Tom Zander]

From all the criticisms against OP_GROUP, the one expressed by Mr. Fyookball has me the most convinced - that we change the principal operation mode of script evaluation.

Jonald made an overly dramatic blog post that has very little substance and a lot of fear and doubt creation. If you refer to my yours post you'll see the same point stated under 'criticism'. The issue wasn't being hidden, it has been evaluated and a solution is suggested for a future hard fork.

What is being ignored here is that BCH is 4 years behind the competition, we don't need perfect solutions that cover all usecases. We need to continue growing and not bet all the money on one horse. I don't have any problems with multiple solutions similar (but not quite the same) problem. The question you should ask is why do some people try to come up with problems.

But please try to keep it civil, though.

You and I are on the same page, this is my wish too. Someone finding whatever reasons to call me horrible things, that's not easy. My respect for people like Roger Ver goes up a little in situations like this.

 

[bitsko]

tom I think you're toxic

 

[Christoph Bergmann]

I'm not sure if I understand this correctly ...

The best example I can give, is one I created. By utilising nChains patents to implement Cryptonized Cash as an on-chain alternative to Counterparty, I am ensured that I have the best on-chain implementation possible for my use-case.

https://www.yours.org/content/intellectual-property-and-bitcoin-da2ba9599306/

 

[hodl]

You do. The author is merely making the incorrect assumption that nchain's work is superior to anything else.
[doublepost=1519492957][/doublepost]

adoption

Or dilution

 

[Christoph Bergmann]

It seems to be more than just a mere assumption