Gold collapsing. Bitcoin UP.

[satoshis_sockpuppet]

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

But that problem exists with existing op_codes already.

And again, IP laws are so fucking crazy and anti-innovation... Ah fuck the bureaucrats..


In regards to activating OP_GROUP:
I'd be happy with BCH if no new operators were ever introduced and the developers focused solely on building a worldwide currency and payment system. But as far as I can tell, OP_GROUP looks like a harmless addition that apparently some people like to see (afair Jihan was interested in that).

I don't see why we wouldn't use miner voting on the BCH chain for code changes like that... It's the obvious solution for that problem.

 

[Christoph Bergmann]

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...

I don't think so. If Amaury does not like OP_Group, or does not think it is safe, or not enough tested and discussed to be sure it is safe, he should not merge it for political reasons.

But for political reasons I suggest he explains why he does not want to merge it, or why he supports his team to not merge it, and points out, if he ever wants to merge it, or not, and why not, and what should happen to make him merge it.

 

[bitsko]

https://www.reddit.com/r/btc/comments/7zpo63/op_group_potentially_dangerous/
[doublepost=1519408429][/doublepost]When I voted in favor of Andrews colored coins implementation I was voting in favor of doing something, anything related to implementing colored coins on BU.

I was not voting to ram a soft fork through that could risk an emergency hardfork down the line.

there is more than one way to implement colored coins, it is not worth it.

I'm in charge of next to nothing but I can assure you I'm entirely opposed to this soft fork notion, and mildly offended at the drama.

 

[deadalnix]

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...

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

[doublepost=1519409029][/doublepost]

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.

Interpretation 1: I'm power hungry monster.
Interpretation 2: I actually has some good advice for BU.

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.

 

[bitsko]

"I hereby propose that Bitcoin Unlimited, as a commuity, will revolt."

left leaning rabble rousing

"- 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"

why do you seperate the other opcodes from opgroup, look to vet them to a higher standard and push through a soft fork which doesn't need agreement from those running the software. it just depreciates the software and guides the network in a direction without their agreement.

"- ask mining pools to let users decide which Bitcoin Cash node they use"

I don't understand but it Is perhaps the least offensive part of your post.

"- spin up more Bitcoin Unlimited nodes"

for show only, the impetus being opposition instead of decentralization. ultimately whatever excepting the wrong foot approach.


"- lobby with XT and parity for our case
- brigade reddit, the mailing-list, the slacks and so on with our complaints against BitcoinABC"

thank goodness you recanted I was worried you would next make signs and or chain yourself to a door.

"- lobby freetrader to distance himself from BitcoinABC"

I see your politics, they are left leaning. does he have free choice here?


"- pledge that Bitcoin Unlimited will never adopt software that is patented like CSW announces
- distance from nChain"

this stance has no merit.


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

grr. I still run ABC when I want to have the full blockchain. I support BU but since the node crashes I wait for hardening. isn't this hardening funded by Nchain working with SBI? pointless nchain opposition. your anti business tendencies are duly noted mate.

thank goodness we have deadalnix who has built a strong track record of not having exploits take down the software.

 

[hodl]

I was surprised by this clash of opinions about the OpCodes.
I see no problem yet with the Satoshi deactivated OpCodes (yet) and I didn't find any reasonable argument from critics of these.

Are these OpCodes, if implemented correctly and without bugs, dangerous for BCH?
Someone explain to me why, please.
They USE the blockchain space to read/write and execute some code, nothing more.

On the other side, the OpCode Group allows people to USE satoshis to represent tokens.

This is the difference between using pencils to write on paper and using pencils to write on pencils. If the number of pencils is limited, you have a problem. And even if you write on smaller and smaller pieces of pencils, the problems don't go away, just change.

If you have these pencils used as money, you have the problem of using a widely consumed commodity as money. The problem is the price is made at the margin of demand and offer; your money value raises if there is an increase of use and if there is an increase of saving there is an increase of costs in issuing tokens.

As @rocks wrote, an attacker could SPAM the UTXO with Gigabytes of satoshis and make too costly to manage the UTXO.
Another problem is, even without a SPAM attack, these satoshis are removed from circulations.

This force the price up of the remaining usable coins. Add hundreds, thousands of ICOs, tokens, etc. on a continual basis, adoption of BCH for payments, and you end with satoshis worth a penny or more, maybe a lot more. And this would make issuing tokens on the blockchain untenable.

If you increase the divisibility of BCH from 10^8 to 10^16 you decrease the costs of issuing tokens but increase exponentially the possible bloating of the UTXO.

Menger defined money as "the most re-sellable good". To be the "most re-sellable good" something must have no use per se. Or better, the cost of using it would be greater than the utility derived from doing so, so no one would use it in that way.

BCH's miners main business is selling space in the blockchain, they get paid with the rights to write the blockchain itself. Then they can sell these rights for goods and services.
The miners should never support any use that "freeze" these rights making them unavailable and increase the future costs of using these rights for everyone (UTXO Bloat) potentially forever. Because this cost increase damages their main business.

In this way, OP_GROUP appears to be bad for fungibility; one class of dumb coins and another for industrial uses (like gold). As I once argued against SC's, it's not clear that continuous, potentially massive removal of Satoshi's from circulation will only ever result in ever escalating prices of the dumb coin. Could be the opposite actually, although I can't be sure. For sure, you can count on likely >95% of these OP_GROUP assets to fail, potentially permanently removing those BCH from circulation. There is a real danger of real deflation in that case. I'm not sure if that will result in intense hodling, dumping from flaws in the economics, or nothing at all.
[doublepost=1519410033,1519409382][/doublepost]One distinction from gold industrial uses is that these ancillary OP_GROUP assets, and for sure their related meta currencies (like XCP) are going to be used entirely for speculative purposes and essentially cost nothing to create (think ICO's) , except for the Satoshi's burned to color. Gold's industrial uses otoh have real world demand

Think of the USD as a somewhat poor analogy as a world reserve currency, and even gold coins when they were popular as currency . None get burned when invested in other assets. They merely change hands. ignore inflation for a moment.

 

[hodl]

I was going to throw up a reddit post on this but I'm busy all weekend so I'll just leave it here for discussion:

If you have a problem with interested parties adding infinite amounts of currency (BCH) to the system, why don't you have a problem with interested parties removing infinite amounts of BCH from the system?
[doublepost=1519412160][/doublepost]Is this just another iteration of "devs gotta dev"? Sorry.

 

[hodl]

"a type system"

Can you explain this further?

 

[adamstgbit]

But that problem exists with existing op_codes already.

And again, IP laws are so fucking crazy and anti-innovation... Ah fuck the bureaucrats..

yup. and he's already claimed IP on all kinds of crazy tricks you can do with a bitcoin.
is this fine? is this not fine? that a completely different question then " are the OP_CODES fine"

In regards to activating OP_GROUP:
I'd be happy with BCH if no new operators were ever introduced and the developers focused solely on building a worldwide currency and payment system. But as far as I can tell, OP_GROUP looks like a harmless addition that apparently some people like to see (afair Jihan was interested in that).

I don't see why we wouldn't use miner voting on the BCH chain for code changes like that... It's the obvious solution for that problem.

I guess BU has no choice but to keep up and add the codes in, ( are the new op_codes a hardfork??)
Not sure I agree with you, bitcoin isnt only about worldwide currency, its also about programmable money.

OP_GROUP, i don't get why anyone would be pushing for its release in may, IMO it might not even be usable. who wants OP_GROUP in may? i'd like to know what you think of the problem it creates, which is unlimited UTXO growth

 

[lunar]

On another note, I think those who think that it is no problem if nChain has patents on part of BCH, I urge you to think this through. CSW and the rest of nChain can be the most well-hearted persons on the planet, but it would potentially still pit the operation of BCH against the U.S. legal system.

https://www.lens.org/lens/search?p=0&v=table&inventor=WRIGHT CRAIG STEVEN

This was linked to today. It's clearly been there publicly, for anyone to see in some cases 5+ years. I'd bet there are many more too, but no one has bothered to do the legwork. (myself included) Some issued in the (US) some (EU) and others worldwide.

Generally speaking patents may be granted for any "new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof"

(US) -To be patentable, an invention must also be "novel" and "non-obvious," as determined by 35 U.S.C. 102 and 35 U.S.C. 103, respectively. That means a patentable invention can neither have existed before, nor be an obvious improvement or alteration of a previously known invention, which could be determined by someone with reasonable skill in the art encompassed by the invention.

It's my understanding that the disabled satoshi OP_Codes are simple arithmetic functions. Addition multiplication, division, concatenate, etc. Most of which can be found here from: @shadders
https://github.com/shadders/uahf-spec/blob/100a677a41305907951a021715ac06be7e749c6b/reenable-op-codes.md

In other words all the OP functions themselves can not be patented. The primary uses of the OP_Codes are "obvious" not "novel" and even if that were the case, they would be considered "prior art" as they are in the original codebase. For nChain to have anything useful, and be granted a patents they must have developed new and novel methods of using these simple arithmetic functions. Here is just one example i found in that list. Blockchain Implemented Counting System And Method For Use In Secure Voting And Distribution

There is a gulf of difference between something like this, that would work 'on top' of the Blockchain and what Blockstream tried to do by embedding Segwit into it.

https://falkvinge.net/2017/05/01/blockstream-patents-segwit-makes-pieces-fall-place/

This current drama is not a good image for BU.

 

[adamstgbit]

massive removal of Satoshi's from circulation

there's too many Satoshi's aviable for this to be an issue. i think.

 

[hodl]

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



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

Yeah, I agree. NONE of these OP_CODES including OP_GROUP were discussed with the community especially from a practical economically based perspective. Devs can't say they aren't major changes even if most of them were disabled by Satoshi or just involve math. This is because they DO open up a myriad of applications that DO potentially have huge economic consequences as I've alluded to already. Otherwise, devs (and potentially vested economic interests) wouldn't be pushing so hard for this.

Once again, I'll apologize that sound money is boring.

 

[lunar]

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?

 

[hodl]

there's too many Satoshi's aviable for this to be an issue. i think.

Gavin once provided a calculation that 21M coins equated to about a $penny per Satoshi as a counter to the allegation that Bitcoin doesn't provide enough monetary units for a viable prospering economy that the USD could transition to. That's important because in the case where BCH becomes a worldwide reserve currency, you do want to be able to buy a coffee with a few of these. It really won't help if it costs one satoshi to buy a house :/ Hard forking to 10^-16 isn't a great/easy solution either, imo.

 

[adamstgbit]

Gavin once provided a calculation that 21M coins equated to about a $penny per Satoshi as a counter to the allegation that Bitcoin doesn't provide enough monetary units for a viable prospering economy that the USD could transition to. That's important because in the case where BCH becomes a worldwide reserve currency, you do want to be able to buy a coffee with a few of these. It really won't help if it costs one satoshi to buy a house :/ Hard forking to 10^-16 isn't a great/easy solution either, imo.

the colored coins actually increase the amount of "money" BCH can represent.

its estimated that if bitcoin would "take over the world!" each coin would need to be worth ~3million each in order to be able to satisfy all the economic activity.

BUT now we have satoshi that could potentially represent far more value then 1penny. suddenly the the above estimation no longer many any sense !

colored coins actually end up creating more BCH supply, since less BCH is required as more colored coins are used.

?maybe? this is hard to really make sense of....

 

[Otaci]

Do you think every risk associated with those op_codes have been assessed and eliminated? Is it easy or hard to determine these risks?

I just want to note that I have seen this and will respond, but it will take some time.

For me, as a laymen, 9 OP_Codes sound like 9 sources of risks

Just to note that these can be grouped into four groups:

• bitwise logical - OP_XOR, OP_AND, OP_OR - these are all very similar to each other, the risks will be the same
• arithmetic - OP_DIV, OP_MOD - these are also almost identical to each other
• OP_CAT & OP_SPLIT - these are counterparts to each other
• OP_BIN2NUM & OP_NUM2BIN - these are also counterparts

 

[adamstgbit]

@Otaci
divide and modules but no multiple ? why not?

 

[Otaci]

Can you explain this further?

It was an off-the-cuff remark. The script language doesn't have strong data types. You could say that the only type is an array of bytes. However, some of the operators do interpret data as if it were a specific type: OP_IF interprets the top value on the stack as a boolean, OP_1ADD interprets the top value on the stack as a "numeric". This can cause issues, for example there are specific conditions that an array of bytes must fulfill to be considered a valid "numeric" value, the simplest of which is that it must be a maximum of 4 bytes long. If you had a byte array on top of the stack that was not a valid "numeric" value and called OP_1ADD, the script would fail (with the result that the script could not spend the input, the transaction would be invalid).

The "off-the-cuff remark" was something like "it sure would be nice if we had a type system, all these problems would go away" (alert: massive paraphrasing). Now, no-one is suggesting that we add a type system to the Bitcoin Cash scripting language, as far as I know. But it did trigger the thought process for me of "maybe we can introduce opcodes that encourage script developers to think along the lines of types, even if we dont have types, and these opcodes would fix the issues we were currently having".
[doublepost=1519418790][/doublepost]

@Otaci
divide and modules but no multiple ? why not?

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.

 

[bitsko]

iirc there is more than one way to go sub satoshi. adding more zeros is the obvious one but apparently it is also possible to use fractions beyond that point somehow.

what a great problem to have, to map the m2 supply or whatever..

 

[Tomothy]

@rocks: That is a very fair point. I got that impression directly reading CSW's tweets, but for fairness I should say I don't know whether BCH is encumbered directly by them, nor whether nChain plans to insert patented stuff, opcodes or similar, into the chain.

EDIT: I am talking about this:

Doesn't sound good IMO.

@rocks and @adamstgbit

So this is a bit delayed and I apologize for that but I wanted to comment on the above. There have been hundreds of patents filed concerning blockchain technology over the last four years and no real patent lawsuits, YET.

We know BOA has patents, Blockstream has patents, MANY entities have patents on this tech and are sure to start attempting to extract rent once the eco-system is able to support that. I think the industry and current price points are still to nascent to address this. I also think it's naive to think that patents won't be used both in an offensive and defensive manner. I think the patents apply to both onchain technology, off-chain technology, and side-chains and tokens and maybe even some of the larger coins.

Prior to the actual fork, some significant research took place to ascertain whether Segwit was in fact encumbered by any existing patents, who those patent holders were, and what stance they held. Afaik, there may have been an agency patent, along with an entity involved with digital device signing/encryption along with possibly others. Of those company's one has a history of vigorous patent litigation, rent/royalty seeking behavior, and isn't anyone we are friendly or familiar with.

Although prices have increased over the last year the overall virtual currency marketcap continues to be incredibly small. The players could seriously buy everything and ask for more so to a certain extent worries about the patent issues are premature. Once the litigation starts I think it will be awful and will go on for years and could result in the elimination of coins. You guys thought the blocksize war was bad, wait until the patent wars begin.

**Edit

I saw the post with regard to the 2013 patents. I will suggest that I think it is HIGHLY likely that there are patents pre-dating 2013. So in terms of a patent defense agreement, I'm not sure that it would be practical. Ideally, you want to prevent a situation which Bitcoin currently faces, that is a reduction of it's overall market dominance. One means to achieve such market dominance would be entities litigating on behalf of the currency. Since these are for the most part global peer to peer entities, you can't stop usage all together, but you can hit the on/off ramps, i.e., the exchanges, along with large multi national entities or trading firms who have sought to use that coin to achieve economies of scale. One means would be to charge licensing fees, the other would be to outright kill the coins infringing on the patented technology.


WRT to the Op_Group debate, I read the below article linked previously I believe,
https://medium.com/@jonaldfyookball/op-group-potentially-dangerous-3720464a2ddc


"Once an op code reaches outside the interpreter"

Since op_group does the above, this seems inherently like something that could have unintended consequences and needs testing. Regardless of whether any of these new opcodes are added, specifically as it relates to op_group as from my understanding the 9 expected additions are relatively uncontroversial, miners will have to run this code. Since miner's depend on stability and like seeing that things are stable and were tested, how is there any expectation this would be added and ready by may?