Gold collapsing. Bitcoin UP.

[Justus Ranvier]

I still think colored coins are a great idea and have thoughts to get around this, but first wanted to hear people's thoughts on the above.

OP_GROUP is probably capable of tapping into the ERC-20 hype and convincing some scammers to launch their pump & dump on BCH instead of ETH.

If support for those tokens ever became demanded by customer I would support them in a product, however I'd never launch a colored coin product based on OP_GROUP (or ERC-20 for that matter).

Any non-trivial, non-fraudulent, application of colored coins is going to require supplemental infrastructure that Bitcoin miners are not going to be able to provide through the protocol, even with OP_GROUP.

Those applications are better off using EPOBC.

 

[hodl]

i certainly haven't seen any public discussions about these OPCODES on any forums. not that i go to a lot of them but i'm pretty sure this was sudden and non transparent.

as an aside, just got off the phone with Genesis trading. they're having trouble sourcing BCH; all the selling from Xapo, BIT, etc last year has dried up since the beginning of the year. hang tight.

 

[rocks]

OP_GROUP is probably capable of tapping into the ERC-20 hype and convincing some scammers to launch their pump & dump on BCH instead of ETH.

If support for those tokens ever became demanded by customer I would support them in a product, however I'd never launch a colored coin product based on OP_GROUP (or ERC-20 for that matter).

Any non-trivial, non-fraudulent, application of colored coins is going to require supplemental infrastructure that Bitcoin miners are not going to be able to provide through the protocol, even with OP_GROUP.

Those applications are better off using EPOBC.

I agree with all of that. I do not think miners should need to process or validate colored coins or other additional features. I do think there should be the ability to better "connect functionality to Bitcoin without requiring miners to do everything". There is a balance here and OP_GROUP leans too far towards putting the burden on all nodes and miners. But for now I was just curious if people had the same concerns with OP_GROUP as I have or if there were other concerns.

 

[awemany]

@rocks, @Justus Ranvier : Yes, fair points!

But this is where I tend to agree with @Christoph Bergmann and @hodl: If I look at @theZerg's document regarding OP_GROUP, I think I might be missing a more balanced section with the drawbacks. I think the 'don't try to be the kitchen sink' argument @rocks made is quite important. Maybe we should indeed avoid introducing another balance scheme.

But where even is the document regarding OP_XOR?

Any dev should put himself into the shoes of the wider BCH community and ask himself whether it is, after reading the accompanying documentation, clear to everyone why we're going where we're going a) and b) it should be clear to everybody how that decision was arrived at and who will decide it.

Someone who about knows how Bitcoin works and about knows how script and/or Forth works should be able to read it, follow it, and say "Ah, this is what is possible with that, makes sense!"

That is not asking for too much, IMO.

And then, on another page, I think @deadalnix is a capable dev but BCH is a bit ABC heavy for me as well.

Which likely lowers the trigger level at which people get "WTF?" moments. I think what @singularity proposed might help there.

Sure, OP_XOR is simpler than OP_GROUP. I am not asking for 5 pages. I am asking for a single page or two with an example script plus an argument from an actual use case, links to further examples and a believable risk assessment on what might happen in the adversarial case if enabled.

And I have seen some arguments on slack that hinted that maybe there doesn't even need to be a public deliberation of sorts on this.

And I think that is very wrong.

 

[hodl]

@awemany maybe the governance system that you seek is as simple as having @theZerg code up whatever alternative proposal/fork he wants (my recommendation is simply 32MB and no more), putting it up on github in finished fashion now with a planned activation in May, and then actively communicating/convincing the ENTIRE community to run his software in the interim as a signaling mechanism that the community is in agreement? miners are only a subset of the community and can and should talk more, TBH, about what their priorities and intentions are. but we can't force them so the best we can do to gauge sentiment is to talk about it in open communication venues that include everyone.

 

[awemany]

@hodl: Yes, maybe so. It would be great if it is staged, though, so that all sides can prepare.

Imagine that OP_GROUP is preferred by the miners. Imagine they activate it. That would leave ABC with a sudden incompatibility that they could not plan for and I think that's potentially highly annoying as well.

I think we want the HP minority to follow the majority but without kicking the minority out, also not intermittently, if possible. Smooth operation.

This is why I think it is should be a contest with stages to go through. "Preliminary", "Confirmed", "On-Chain-Activation". Or similar. Details to-be-bikeshedded. After the "Confirmed" stage, it would be clear for every dev where things are going and ABC would pick up and integrate OP_GROUP, or at least provide a stub that is compatible with and not interfering with any implementations running on the rest of the network.

----

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. I am not sure that we want such a situation at this stage. It might be unavoidable eventually. But I would definitely not cheer it on.

Luckily, SWPATs are mostly a U.S. thing. But I still think this might open a can of worms and, especially when we haven't won against BTC yet, become a major setback for BCH.

Putting my tinfoil hat on [And I really don't mean to imply anything here, for once I do think CSW is simply an older more conservative guy in this regard and truly thinks (software) patents are good and I also do not see any incentive for nChain to do this] an attack by trying to divide a coin through the U.S. patent system would be a thing businesses threatened by Crypto might try.
[doublepost=1519242764,1519242104][/doublepost]@hodl: We cannot force the miners to talk, but I think an explicit request, backed with a BUIP, to give a public reply on such a voting/competition scheme (or even (adapt and) implement it) by most major miners through the BU president would carry some weight. I think it is worth trying.

 

[painlord2k]

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.

 

[hodl]

>That would leave ABC with a sudden incompatibility that they could not plan for and I think that's potentially highly annoying as well.

1. we've identified a disagreement
2. there is no way to easily determine or come to a concensus
3. the solution is for @theZerg to code up in final fashion within BUCash what he wants and what he believes the community including miners will accept
4. put this code up on github NOW so that anyone can begin running it but with the new rules not yet activated.
5. planned activation of the new rules in May, as of a certain blockheight, the same day as the ABC proposed hard fork
6. the community, including miners, can begin running @theZerg's code between now and then as a signal that his beliefs and strategy are in the best interests of continued scaling and development of BCH.
7. ABC and BUCash will be able to gauge community sentiment of both options in the interim by monitoring node counts, miner coinbase signals, and forum sentiment so they won't be surprised at the final outcome.
8. if community sentiment is against ABC, they can cancel their hard fork version come May or roll the dice and go thru with it. same for BUCash.

 

[rocks]

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.

Does nChain have patents on parts of BCH? My understanding is they only have patents on their off chain usage aspects.

Fully agree that BCH must be kept IP clear. BCH is an open standard that should not in any way be encumbered.

A good analogy to me is the html standard. This standard is the base layer and is open and IP clear, however people should be able to develop IP on specific and narrow uses on top of that base layer. The problem is when obvious or wide usages of that base layer are patented. For html things fell down when patents on hyperlinks were granted or Amazon received it's one click patent. To me BCH is the base layer similar html, and nChain should be similar to complex web applications build on top of html, not hyperlinks...

Another good example is the JEDEC DRAM standard. This is suppose to be an open standard where companies contribute work with the caveat that everything in the standard is IP clear. In 2000 Rambus slipped some of their IP into the DDR standard and then sued everyone in the industry, who had to use the standard. Here BCH is the DDR standard and we do not want nChain being Rambus.

If nChain has broad patents that prevent other entities from performing useful counterparty type functionality at all, then that is an issue. If their patents are specific to their usage and others can develop counterparty functionality by another method or entirely new functionality, then that is how it should work. I haven't seen an analysis of their patent portfolio so don't know where we are. But BCH needs to make sure nothing nChain specific is added.

But where even is the document regarding OP_XOR?

The initial satoshi client. When BCH forked reactivating original opcodes that were simple and obvious was in my top 4 things to do. These are not new codes so I feel they do not have as high of a hurdle to reactivate as an entirely new opcode. To me an entirely new opcode needs to achieve a higher testing bar and a higher justification bar. Clearly there is disagreement on this front.

 

[awemany]

@painlord2k : For the record, and I know that opinion is highly unpopular, but I see no fundamental problem with pushing the responsibility for long-term storage of UTXOs back to those who caused them or received them

Also, increase in UTXOs vs. increase in load is another value / cost tradeoff.

 

[hodl]

Another problem is, even without a SPAM attack, these satoshis are removed from circulations.

i really don't like any idea that removes satoshi's from circulation. we have a bad enough reputation as it is of being a fixed supply deflationary currency. if you want to exacerbate the hodling problem even more at the expense of using it as a currency, remove satoshi's from circulation.

 

[awemany]

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

If this means patents on how BCH operates, he would essentially have a handle to also say to forks "nope, you are not BCH, you don't get the patents" and, unless the fork removes any traces of patented stuff from BCH, means he (or nChain) would essentially have a direct say in which chain is BCH and which isn't. (In the jurisdictions where his patents are valid)

I might be reading this wrong, however, and it might "only" apply to stuff happening off the chain. I still do not like SWPATs creeping into the space like this. As I said, Blockstream at least had somewhat of a free use policy.

[doublepost=1519245115][/doublepost]

The initial satoshi client. When BCH forked reactivating original opcodes that were simple and obvious was in my top 4 things to do. These are not new codes so I feel they do not have as high of a hurdle to reactivate as an entirely new opcode. To me an entirely new opcode needs to achieve a higher testing bar and a higher justification bar.

That is o.k. but the bar shouldn't be zero. They have been deactivated for a reason. OP_XOR allows some kind of entropy mixing scenarios. Give me a simple 1-2 page argument for why that is a good idea.
I don't mean you to give me that now. I mean this should come along with such a change!

 

[hodl]

i really don't like any idea that removes satoshi's from circulation. we have a bad enough reputation as it is of being a fixed supply deflationary currency. if you want to exacerbate the hodling problem even more at the expense of using it as a currency, remove satoshi's from circulation.

this was actually one of the main problems i had with SC's; whisking them offchain with the flippant argument from Core that if a SC failed, no problem, "it'll just increase the value of the remaining coins"-->facepalm.

 

[rocks]

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.

This is the root of the issue.

People should look at how JEDEC handles IP and the open DRAM standard. They developed very clear processes and rules after Rambus successfully extracted billions from the industry.

There should be similar rules and processes for companies that contribute to Bitcoin Cash in some manner and also develop IP portfolios for functional usage on top of the standard. If this is not done a real problem will happen at some point. nChain should be constrained and follow the same commitments as JEDEC forces on Intel, Micron, Samsung, HP, etc.

Luckly JEDEC has a process that works now and is a worthwhile example and starting point. ABC and BU should seriously look at it IMHO.

 

[rocks]

If this means patents on how BCH operates, he would essentially have a handle to also say to forks "nope, you are not BCH, you don't get the patents" and, unless the fork removes any traces of patented stuff from BCH, means he (or nChain) would essentially have a direct say in which chain is BCH and which isn't. (In the jurisdictions where his patents are valid)

My assumption (hope) is CSW is referring to usages on top of BCH that are not possible on top of BTC because of BCH's expanded functionality (opcode support).

I don't see how anyone has patents BCH functionality even with the new opcodes, since this has all been in the public domain for years now. You can't patent "A bitcoin blockchain with OP_XOR" for example. You could only patent some script code that performed some function and happened to use OP_XOR. In this case others are free to develop different usages that also happen to use OP_XOR.

It could be that CSW has patents on usages as described above and intends to use these to block BTC from enabling the same usages. So if BTC started to fall behind and activated OP_XOR, well they could but the known usages of OP_XOR are owned by CSW and he explicitly blocks people from making practical use of these on BTC.

These are "hopes", the past 4 years have taught me to trust no one in this space.

All the more reason to develop a JEDEC like approach to IP...

 

[painlord2k]

@painlord2k : For the record, and I know that opinion is highly unpopular, but I see no fundamental problem with pushing the responsibility for long-term storage of UTXOs back to those who caused them or received them

Also, increase in UTXOs vs. increase in load is another value/cost tradeoff.

Essentially, miners should veto such uses like OP_GROUP or tax them to oblivion.

 

[adamstgbit]

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. I am not sure that we want such a situation at this stage. It might be unavoidable eventually. But I would definitely not cheer it on.

CWS's patents suck, i wish he'd do everything for free and give it away to everybody. then again... if he did that maybe he go out of biz, and stop trying to produce useful stuff... hmmm...

But that's not the issue here, even if we believe that its terrible thing all of CSW patents, and he'll make a whole bunch more ridiculous / crippling patents which uses the OP_CODES. This doesn't give the OP_CODES themselves less merit.

 

[adamstgbit]

thinking about the UTXO spam attack that the OP_GROUP would open up.
its not a problem...

because miners don't need to validate what they dont include in their block. so a miner can still mine BCH and not bother with the all the UTXO's of all the tokens
And this probably applies to individual tokens. a miner could choose to which tokens he will validate and add to his blocks.
[doublepost=1519258518,1519257737][/doublepost]miners would have to preform some automatic cost Vs benefit analysis on each token, and automatically drop tokens that have big UTXO sets and are not paying enough in TX fees.

hmmm maybe this is actually a big problem of OP_GROUP, theirs no way to ensure miners will continue to support the tokens. As soon as a token becomes unpopular, it might be Profitable to stop including any TX from that token,in order to drop the huge UTXO, rather then hold the UTXO in order to process one TX every once in a while. and that token would die...

 

[Christoph Bergmann]

CWS's patents suck, i wish he'd do everything for free and give it away to everybody. then again... if he did that maybe he go out of biz, and stop trying to produce useful stuff... hmmm...

But that's not the issue here, even if we believe that its terrible thing all of CSW patents, and he'll make a whole bunch more ridiculous / crippling patents which uses the OP_CODES. This doesn't give the OP_CODES themselves less merit.

I agree, but have to add: Csw wanting patents is no strong reason to add something, if it is a reason at all, and it is a very bad reason to assess it with less strict categories than other proposals.

 

[adamstgbit]

Agreed.

But it MIGHT be a reason for other crypto's to rush and implement these OP_CODES and file their own patents ahead of CWS! but i guess there's almost no chance of that. crazy though.

anyway the community has till may to find a legit reason to stop this fork. this doesn't seemed rushed to me.

i hope CWS gets rich because of his patents, seriously, but i get the feeling his isn't doing patents for the money, hes using patents to give BCH an advantage. pretty sure i remember watching a video where he said he would allow anyone to use his tech on BCH for free, and tax the usages outside of BCH.