Gold collapsing. Bitcoin UP.

[rocks]

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.

That solution essentially means that colored coins using OP_GROUP would not be processed, or would be processed very slowly, essentially making the approach work. The reason counterparty's approach works better is because miners only have to store the OP_RETURN data packet and let processing of colored coins be performed by other entities interested in doing so.
[doublepost=1519261204][/doublepost]@adamstgbit That is aligned with what I have heard, although I have not seen a source from CSW yet. It makes sense with what his attitude seems to be.

 

[adamstgbit]

That solution essentially means that colored coins using OP_GROUP would not be processed, or would be processed very slowly, essentially making the approach work. The reason counterparty's approach works better is because miners only have to store the OP_RETURN data packet and let processing of colored coins be performed by other entities interested in doing so.

the colored coins using OP_GROUP would be processed by all miners, IF they actually provide miners with a good reason for the miners to hold their UTXO set, that reason would be continues fee pay TX these colored coins generate.
I think miners could pick and choose which colors they will service.
all the spam colored coins would quickly get dropped by all miners. ( unless the spammer pays them well enough ¯\_(ツ)_/¯ )

same goes for the nodes. Having millions of colored coins on the blockchain wouldn't require nodes to hold millions of UTXO's, nodes could ignore the coins they don't care about. it would make blocks bigger, but so does counterparty's approach...

the only real "advantage" that counterparty has, is that its "spam coins" are on equal footing as the other counterparty-tokens.

However my understanding (please correct me if I'm wrong on this) is OP_GROUP introduces the ability to create near infinite supply of tokens that are spendable. As a result it is easier to focus a spam attack on bloating the UTXO set. Instead of churning the same tokens on storage, an attacker can create tokens and create as many spendable outputs as they desire. The current 8MB would allow for bloating the UTXO set by 1GB per day. Doing that on the blockchain is not an issue, doing that on the UTXO set is.

@rocks I think OP_GROUP's UTXO spam-attack, might be avoidable, relatively easily.

 

[BCH King]

This is quite a big problem because we can't expect everybody (library mantainers, software developers, wallets, exchanges, etc) to rewrite all their code at the fixed date of a fork.

Why not?

It can be phased in, like:

if (blocknumber > 800,000)
maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I, The Bitcoin King, can put an alert everyone to make sure they know they have to upgrade.

 

[Christoph Bergmann]

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.

Ah, I remember seing him telling his audience he had run a AI on the blockchain, but it was killed by fees. I wonder why he needs new op_codes, if everything's possible with old codes ...

After having seen a lot of CSW's comments, promises and claims, and having never seen any software from him, I think it is wise to just make his comments a non-factor when planning technical upgrades.

 

[Bagatell]

I'm a sucker for omens. I just felt a ML 3.9 earthquake and minutes later see this -

Huh "Moving to Acapulco? Me too!"

Two quakes while I was at Anarcapulco - any one else feel them?

 

[Zarathustra]

 

[Dusty]

Why not?

It can be phased in, like:

if (blocknumber > 800,000)
maxblocksize = largerlimit

Don't fall on Core narrative: not all hard forks are equal.

The hard fork to raise the block size has almost ZERO impact with all the bitcoin software: it's a tiny thing inside the node, you just upgrade it and every piece of software using bitcoin (wallets, libraries, exchanges, etc) has nothing to do at all.
The upgrade is seamless and for that reason there was absolutely no reason to avoid it.

On the contrary, if you change the transaction format, you must develop totally new software that must begin to work, in unison, exactly after the fork block.
This is also quite difficult to develop and test.
Every (unmantained) software out there (everyone of them, and there are thousands) stops to work after the fork.

In my opinion that's total suicide, a total and complete mess for all users and operators, and would totally destroy the usage of the coin doing it.

For example Ethereum regularly hard forks every n months but it does it in a way where old software (and contracts) still works usually with no modifications.

 

[adamstgbit]

@Dusty
the root problem is that their are many many many implementations of the protocol, AND the reference implementation , is probably the messiest one.

ideally their would be lib's built and maintained by a few devs, and everyone else uses these libs to build a node or miner or whatever software.
the lib's interface never changes but the implementation can.
at that point any change to to protocol is a simple matter of update the lib to the latest and recompile.

this is ridiculously hard, because we can not even agree exactly what is the protocol specif code.

but i think bitpay has done something similar to this already, they have various libs for various langs. so you might be exaggerating the problem... i would guess MOST "unmantained" software out there is built on a lib already. or just uses a full node's REST interface.

 

[painlord2k]

I think miners could pick and choose which colours they will serve.
all the spam coloured coins would quickly get dropped by all miners. ( unless the spammer pays them well enough ¯\_(ツ)_/¯ )

the only real "advantage" that counterparty has, is that its "spam coins" are on equal footing as the other counterparty-tokens.
@rocks I think OP_GROUP's UTXO spam-attack, might be avoidable, relatively easily.

Essentially you are describing a system where miners don't support any coloured satoshi transaction unless they are paid for it in advance, for every step.
Problem being, a miner could support a token because it is paid by the issuer and stop supporting it because the issuer stops paying it. The token becomes worthless for the buyers afterwards.
The buyers, being little guys have not the clutch to get miners supporting the system because the costs of doing so are too large for them individually.

I continue to suggest to continue to use the paper (blockchain) and not the pen (satoshis) a medium of record.

 

[adamstgbit]

@painlord2k

your right, the token might be supported at the start, and later the burden of holding that token's UTXO is no longer worth it, so the miners drop that tokens UTXO and stop including TX from that token, and those tokens can't be moved anymore.

theirs no way to avoid this, because we have no control over what a minner puts in his blocks.
maybe this is OP_GROUP token's fatal flaw.

however, "dead tokens" would probably become alive again as soon as a TX with a good enough fee is broadcast. how costly could it possibly be to recompute a tokens UTXO in order to process the fee paying TX?

but this problem is to big... because if these tokens have value and we can place shorts on them at exchanges... then i could do the fallowing:

place MASSIVE short on TokenXYZ
spam that tokens UTXO until it gets so big and bloated, that miners drop it.
tokenXYZ dies.
my short profits massively!

so your probably right...

use the paper (blockchain) and not the pen (satoshis)

 

[BCH King]

Every (unmantained) software out there (everyone of them, and there are thousands) stops to work after the fork.

This is a good thing. https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7

 

[Bagatell]

https://coingeek.com/opcode-proposals-bitcoin-cash-introduce-tokening-functionalities/

“OP_GROUP is the best BCH token proposal because of SPV support and its simplicity. Keep is short and simple. It doesn’t need to be included in a hard fork. Make it a soft fork and activate it on testnet as soon as possible.”

 

[Norway]

https://www.yours.org/content/op_group---introducing-administrative-tokens-f7584a9fc397/

OP_GROUP - Introducing Administrative Tokens
Late last year, two excellent articles were published on implementing Colored Coins in Bitcoin Cash using a new proposed opcode called OP_GROUP. Thank you Andrew Stone for the initial concept, and Chris Pacia for building upon this.

The OP_GROUP approach is elegant, powerful and secure. It is not a fully-blown smart contract system, but does provide very powerful functionality that is sufficient for most use cases. I’m very enthusiastic about its possibilities. I think it needs one small addition to make it even more useful and powerful, and that is the capability to safely transfer the token generation abilities between parties and improve token generation transparency / accountability when multiple groups are involved in token generation.

In a nutshell, the current OP_GROUP token minting and burning processes requires the use of a single set of static private keys. I.e., one or more ‘keys’ are used to issue the tokens, and the locks can never be changed. The keys can thus be given (copied) from one person to another person, but it is not certain whether the first person has retained a copy of his key. In this article, I shall demonstrate how we can use one administrative token as a key to issue other tokens. Since administrative tokens can be moved from one address to another, these administrative tokens can be transferred from one party to another, where the first party no longer has access.

Click the link on top to read the whole article.

 

[deadalnix]

Bitcoin Unlimited teached Amaury to work with Bitcoin, it even paid him for learning how to do Bitcoin.

Sometime, it is better to say nothing than confirming to everybody that you are full of shit.

 

[Zarathustra]

Looks like the project fails. The leading minds are unable to communicate and collaborate. But hey, never expect anything different in a civilized world, the greatest piece of shit ever created (to speak in Craig Wright's lyrics). War and warriors everywhere. Competition is an euphemism for war. We're all full of shit.

 

[Christoph Bergmann]

Sometime, it is better to say nothing than confirming to everybody that you are full of shit.

Seriously, this is all you say to this discussion?

I may be full of shit, as every Core fanboy knows, but it seems the sentiment I expressed is way more than just shit. Better you realize this before it is too late.

Bitcoin Cash was about freeing Bitcoin from Core. Blocksize was the most important point, but just a symptom of the disease. Please don't forget this.

 

[Otaci]

Hello. My name is Daniel Connolly and I have been directly involved in the specification for re-enabling the disabled opcodes. My Twitter account is @connolly_dan and my GitHub is https://github.com/Danconnolly. I primarily work on BitcoinJ Cash but was interested in re-enabling these opcodes and got involved.

I havent been following these forums for a while, so I'm only just seeing this discussion now.

Many years ago, several opcodes were disabled due to a bug in the implementation. These opcodes provided basic low-level functionality such as bitwise logic, splitting and concatenation of binary arrays, and basic math functions on numeric elements. My interest in working on these opcodes is to enhance Bitcoin Cash to provide these basic functions so that others can use them to build more advanced functionality.

The specification for re-enabling these opcodes is here, but its important to note that this specification has undergone many revisions based on discussions and feedback with other developers. The specification was discussed in meetings on 31st January (summary) and 7th of February (summary). We have tried to make this specification as complete as possible, including the analysis of edge cases and impact on interpreter performance. We included an implementation in Bitcoin ABC.

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.

To the best of my knowledge, no-one from ABC or BU has directly contributed to the specification or the reference code for re-enabling these opcodes. Members from both of these teams were in the meetings and had comments and feedback, for which I am grateful.

 

[Dusty]

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

 

[deadalnix]

Bitcoin Cash was about freeing Bitcoin from Core. Blocksize was the most important point, but just a symptom of the disease. Please don't forget this.

If you want be free from core, maybe stop pushing for astroturfing campaigns and spreading lies about me. I have zero interest dealing with petty liars.

Get your act straight, Mr "journalist".

 

[Christoph Bergmann]

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.

I'm just a writer, I'm incentivized to be objective, to follow Core, Cash, Ethereum and so on, and I'm somehow attached to Bitcoin Cash, but this doesn't need to be like this. I'm really not important, but I think I do a good job to tell the German community from achievements of Bitcoin Cash, which would otherwise be not noticed at all or painted with Core narrative. I also think without me Bitcoin.de would not have integrated Bitcoin Cash so fast. My "Big Blockism" made me a target for trolls, and there have been times when it risked to make my relation to my sponsors worse.

If I have the impression, that Bitcoin Cash goes the same way than Bitcoin Core, I don't know why I should support it. The information politics on the op_codes - the clearest information about one of them can be found on blockstream's website, seriously - and the reasons for rejecting op_group created an impression that there is a danger of Bitcoin Cash is going to be governed similar to Bitcoin Core, maybe even less transparent and by even a smaller number of people, which are less experienced with development than Core and don't enjoy the same ecosystem wide trust.

Maybe I'm full of shit, this is all wrong and so on. But it is an impression that has grown with each decision that was made, and I think I'm not the onliest. Maybe it is a communication issue, maybe not, maybe both.

But there is one thing I know: If Bitcoin Cash does not convince the community that it creates a better governance than Bitcoin Core, it will have not much chance to succeed. And if it was an intention or not, if it was an accident or just a misrepresentation or campaigning by liars - the way you act did not do much to strengthen hopes for this.