Gold collapsing. Bitcoin UP.

[freetrader]

The specification was discussed in meetings on 31st January (summary) and 7th of February (summary). [...]

I am happy to answer any questions about these opcodes to the best of my knowledge. Note that I am only one of the people who have worked on re-enabling these opcodes.

Daniel thanks for making yourself available for questions.

The first one I have is whether the February 15 meeting mentioned by @theZerg falls within the same WG as the above. If that is the case, then the summaries above are only part of the picture of the discussion - it seems that on Feb 15 some kind of group decision w.r.t. the cutoff was made and I have not seen this expressed in a WG summary (maybe I did not look at the correct document). Perhaps it's just a matter of waiting for release of that summary, these things take time obviously.

The second question relates to a concern I have that there could be some overlap between new opcodes and software patents, existing or applied. This would be unfortunate, and I hope we can exclude this scenario. In the working group summaries, I see no discussion of potential patent coverage for the new codes (OP_SPLIT, OP_NUM2BIN and OP_BIN2NUM). But perhaps you (or @theZerg , or @deadalnix) can share whether the topic was considered as a risk at all.

 

[satoshis_sockpuppet]

Ok, I am out of the loop...
Is there a possibility of op_codes being patented now??!?

Apparently I am very naive, but you can't really patent something like OP_NUM2BIN? Please tell me, that you can't

 

[awemany]

@deadalnix , @Christoph Bergmann, can we please try to discuss even difficult topics like this one in a productive way?
I understand very well the difficulty of this since there are personal attacks involved, but you are very intelligent people and I'm sure you can handle them with a bit of willpower and patience.

Your cooperation is greatly appreciated.

Welcome @Otaci , and thanks for the infos regarding the opcodes.

Seconded.

 

[Christoph Bergmann]

Thank you Daniel for bringing some clearity in the discussion.

If I got it right, the discussion started in late January, and only one month later you agree to reactivate 9 op_codes? Honestly, I don't know what specific usecase they have. OP_Cat (I think) is best described by Blockstream's MAST experiments. For the other, someone said "a lottery", or "smart contracts" in general. There is some information available, I got some after complaining in a trollish way, but it's not clear.

I never noticed that there was a decision to make Bitcoin Cash the blockchain of smart contracts, and while I look forward to see more options, it is irritating to see some kind of urgency to add so many op_codes to Bitcoin Cash without a public perspection how they help Bitcoin Cash to be a better P2P Cash.

One of the document you linked stated: "OP_REPEAT - nice but presently no use case, maybe in the future if required". This quote implies that you are aware of speficic use cases for the other op_codes. It would be helpful and interesting to present this usecases, each for an op_code, and some predictions how they can help Bitcoin Cash.

 

[Otaci]

As I understood it, the 15th February meeting was specifically to discuss OP_GROUP. I could not attend this meeting (the flu) and did not consider myself to have any expertise on this opcode so my presence was inconsequential. I am not certain what was discussed in the meeting and am also awaiting the summary. I'm sorry, but I can't help you there.

The possibility of patents being applicable was not discussed. It's a good point though. I wrote the specification for OP_NUM2BIN and OP_BIN2NUM, the ideas for them came as a result of the first meeting where "a type system" was mentioned. They replaced previous ideas for an OP_PAD_LEFT opcode and similar. The concept behind them is to encourage script developers to think in terms of types and to provide the means of converting between those types, although types are not enforced within the script language. The root of the problem here is that the size of minimally encoded numeric elements changes depending on the value being represented by the element (the value 256 occupies 2 bytes, the value 124 occupies 1 byte) and this has the potential to cause failures since the bitwise logical operators require the operands to be the same size.

I am not aware of any patent covering those ideas, which unfortunately does not mean that one does not exist.

I dont think it would be possible to patent OP_SPLIT, this opcode has exact equivalents in existing programming languages. But IANAL.

Edited: fixed typo, replaced "operators" with "operands".

 

[Otaci]

The re-enabled opcodes were discussed before, I will look for references to that but as far as I remember they were mentioned when the hard fork schedule for May and November was announced (found one here).

There are plenty of discussions happening between individuals and groups all around. I have only referenced the "kind-of-formal" workgroup meetings, of which the first one I know of on this topic was at the end of January. We had a full specification that was shared with the workgroup prior to that meeting, to serve as a basis for discussion.

OP_REPEAT was just unnecessary. The comment was worded that way because we wanted to leave the door open for including it in a later upgrade if someone had a specific use case and pushed for it. No-one has.

I agree that some use cases would be useful, but at the moment all I have is "they are basic operations that a script language should be able to do".

 

[Christoph Bergmann]

Ok, thank you for this. I had to lol', because I am the author of the article you linked

Having no use cases is a bit unsatisfying, despite I see your case for bringing basic operations to Bitcoin, which can attract developers and applications. One last try: Can you point to things that have not been able / overly complicated with Bitcoin's existing set of op_codes?

And one more question: Do you think every risk associated with those op_codes have been assessed and eliminated? Is it easy or hard to determine these risks? For me, as a laymen, 9 OP_Codes sound like 9 sources of risks, and possibly a lot more when you start combining them in a weird way. If you have a good explanation, why this question just says that I don't understand what I'm talking about, it will be helpful too ...

 

[Otaci]

I will give my perspective on these workgroups, their repositories, and meetings. I'm not sure if everyone agrees with me, but this is how I see them.

They are an optional mechanism for Bitcoin Cash developers to collaborate and cooperate. They are not required, they are not governance. Its a way for interested parties to present their ideas, get review and feedback, and get some sort of confirmation that other Bitcoin Cash developers think the ideas are worth pursuing.

It's also perfectly fine for people to go and do their own thing without participating in these workgroups at all. Bitcoin Cash is an open platform, anyone can contribute.

It was very useful for us to discuss the specification for re-enabling the opcodes in this workgroup. We got excellent feedback and issues were raised that we had not considered. We took this on board and went back and updated our specification, came back for another review and found general acceptance of our ideas.

 

[Tom Zander]

I wrote a yours.org post that many of you guys may enjoy.

"An independent opinion on OP_GROUP " https://t.co/i9JKRY9Hbt

 

[bitsko]

Good day Christoph. I appreciate you making the effort to apologize for the outburst.

I wanted to clarify as to whether you have retracted this position:

I hereby propose that Bitcoin Unlimited, as a commuity, will revolt.
- Reject the reactivated OP_Codes, until there is public consensus about its benfits and the absence of risks
- implement OP_Group as a softfork, gather miner support for them
- ask mining pools to let users decide which Bitcoin Cash node they use
- spin up more Bitcoin Unlimited nodes
- lobby with XT and parity for our case
- brigade reddit, the mailing-list, the slacks and so on with our complaints against BitcoinABC
- lobby freetrader to distance himself from BitcoinABC
- pledge that Bitcoin Unlimited will never adopt software that is patented like CSW announces
- distance from nChain

Be angry. If not, this will become a take-over.

I certainly hope you have dropped such efforts, thanks.

 

[Tom Zander]

The second question relates to a concern I have that there could be some overlap between new opcodes and software patents, existing or applied. This would be unfortunate, and I hope we can exclude this scenario. In the working group summaries, I see no discussion of potential patent coverage for the new codes (OP_SPLIT, OP_NUM2BIN and OP_BIN2NUM).

As CSW (and his company) have almost twice the amount of software patents that Bank of America has, I think its a safe bet to assume he patented some stuff that is part of any Bitcoin Cash node, current and future.

Please note that you do NOT want to go searching for those patents based on the simple fact that if you are aware of a patent and you then infringe it, you are eligible for triple damages. So its better to stay ignorant as you can't fight patents anyway and working around them is rather impossible most of the time too.

The way to "fight" those patents is practically speaking the same way we "fight" the governments. Make sure that our software is run by the largest possible subsection of the world.
With no organisation to attack the only option is to attack each and every user and that just isn't profitable.

Everyone, please consider joining the open source, decentralised (no elected leaders) project http://Flowee.org which uses an open source license that keeps the software open even in the case of developers having patents.

 

[Christoph Bergmann]

Good day Christoph. I appreciate you making the effort to apologize for the outburst.

I wanted to clarify as to whether you have retracted this position:



I certainly hope you have dropped such efforts, thanks.

If I'm not wrong, I still see broad support from BU members for most of these suggestions, also from some independent people developing things on BCH. I think you don't realize the scope of dissatisfaction this affair raised.

There are still a lot of questions unanswered, for example about specific risks and benefits of those op_codes, the argument against op_group is still not convincing, a pledge against using software patented in a way that it can only be used in BCH seems to be at least worth a discussion, and giving miners the choice which BCH-client they mine on is something we absolutely need to settle current and future controversies by hashrate, and "lobbying" for their solution should be the duty of teams in the context of decentralized development. Most of these suggestions don't seems so controversial.

However, I retract from calling to brigade social media. This discussion should be as civil and polite as possible.

I hope the discussion improves until May 15th, the open questions are solved, and everybody agrees on a common road for a safe extention of BCH's functionality. If it will be like "all those op_codes have no clear application, but are a riskless way to open a world of more smart contracts, while op_group has serious risks we want to test intensively", I'm ok with. It's more a question of the procedure than the result.

If the procedure catches on, nearly all of my suggestions will become invalid. My comment was more like a "wake up call" that something has taken a bad path and needs to be redirected, even if this is not possible to do in harmony.

@Tom Zander

As CSW (and his company) have almost twice the amount of software patents that Bank of America has, I think its a safe bet to assume he patented some stuff that is part of any Bitcoin Cash node, current and future.

Are these patents real, or are they just approvals for patents?

In Europe I think software patents do not exist, so maybe it would be nice if you all move here

 

[Tom Zander]

> In Europe I think software patents do not exist

I remember very well the fight we had here in Europe, which we basically lost, about article 52 being interpreted in a way that allows software patents.

Sorry, software patents are also possible in the EU.

 

[freetrader]

Please note that you do NOT want to go searching for those patents based on the simple fact that if you are aware of a patent and you then infringe it, you are eligible for triple damages. So its better to stay ignorant as you can't fight patents anyway and working around them is rather impossible most of the time too.

@Tom Zander , if those patents cover some Satoshi code already, looking at them won't hurt. In that case they need to be struck down and failing that, at least exposed for affecting the protocol.

I think its a safe bet to assume he patented some stuff that is part of any Bitcoin Cash node, current and future.

I cannot come to such a conclusion based only on number of patents. But I do largely agree with your assessment on how to deal with software patents affecting the protocol.

Does anyone think BU (together with others?) pushing for a defensive patent pool for Bitcoin Cash, similar to what Blockstream set up for Bitcoin (BTC), would help as a mitigation strategy?

 

[deadalnix]

I agree with Dusty that it should not be done like this. I apologize for making this personal, deadalnix, this was a mistake which did not help anything.

The problem is not making it personal - well it's kind of a problem, but it is not what I'm pissed about. You clearly lied about me. I never was employed by BU and I was taught not much by BU. In fact I tried to have BU do what ABC did for month before doing it in ABC. I gave BU everything and BU was interested in none of it. BU could have been ABC.

Now ABC opened the door to BU, and you guys come in a shit on the carpet. Let's be very clear here, we as ABC have zero obligation to be cooperative with BU. And yet we chose to create workgroups and I even implemented part of the spec for cash for BU (and classic as well).

I purposefully made zero proposal for this HF and you still find a way to come with a crazy conspiracy theory to make me the vilain. This behavior is the reason why the big block movement has accomplished nothing in the past, and why we are a minority chain right now rather than a majority one.

 

[Christoph Bergmann]

I purposefully made zero proposal for this HF and you still find a way to come with a crazy conspiracy theory to make me the vilain.

Yes, it the public reception of your influence might be overstated, and it was a bad step from me to give your responsibility for things other people did. It was another mistake in a badly worded comment born from anger.

Yet your are the leader of the most important Bitcoin Cash implementation, which somehow makes you a leader, if you like it or not. And with this comes responsibility.

In fact I tried to have BU do what ABC did for month before doing it in ABC. I gave BU everything and BU was interested in none of it. BU could have been ABC.

Now ABC opened the door to BU, and you guys come in a shit on the carpet. Let's be very clear here, we as ABC have zero obligation to be cooperative with BU

I don't like this sentiment, really.

You know, I have been in a lot of talks with BU people and with you at some time, and that I observed the evolution of the relationship between you and BU closely. There are very different interpretations of what was going on. Your opinion represents an extreme point of the scope, and it is insulting for Bitcoin Unlimited devs and their massive role as a hub for big block community, both socially and technically.

I sincerely ask you to reconsider your stance toward BU and develop a more cooperating one.

 

[Tom Zander]

And yet we chose to create workgroups and I even implemented part of the spec for cash for BU (and classic as well).

Ehm, for Classic I coded everything myself, with the sole exception of the DAA algo which I stole by copy-pasting it from ABC. This has quite a bit of a different feeling as you make it sound...

edit; I have to add that during the approach to the hard fork time I had issues with downloading the entire testnet in time for a scheduled test and freetrader jumped in and helped me out by compiling classic and giving me the logfile afterwards. Now there is a helpful and great guy.

 

[adamstgbit]

Ok, I am out of the loop...
Is there a possibility of op_codes being patented now??!?

Apparently I am very naive, but you can't really patent something like OP_NUM2BIN? Please tell me, that you can't

no it sounds more like their will be patents on specific usages
example getting bitcoin to do __________ by using OP_1 +OP_2 +OP_3 / OP_5 mutli sig the result... etc

 

[Tom Zander]

I purposefully made zero proposal for this HF and you still find a way to come with a crazy conspiracy theory to make me the vilain

There is a simple way out; publicly state (and follow through) ABC will include the OP_GROUP change in the ABC release meant for the May hard fork. No ifs, buts or other funny stuff.

Talk is cheap, actions speak louder...

 

[adamstgbit]

why can't we just do OP_GROUP in June? is the fork in May a hardfork? and OP_GROUP would be another hardfork done at the same time?