Where is the "a stripped down non token non altcoin embedded BCH protocol," and how does it let me hypothecate my coconut cart and split it into 100 affordable pieces so that I can collect unengaged capital from my peers and use that to buy another cart?
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
the only reason i've come around to the ABC proposal come May is that even though OPRETURN is going to expand to 220B, at least these insertions can be purged from the UTXO set and not cause some weird perverse economic effect (i hope). i'm sure XCP & Omni are going to jump all over this and start embedding even more data into it. in the bigger pic though, i seriously doubt XCP can or will compete with the BCH price in the long run, altho i'm still quite concerned with dilution and crippling. by my understanding, OPSPLIT is new. i'm not in favor of it from a purely "stick to the existing codes until we deem them safe" view. my guess is we have to give some concession to all the devs wanting this stuff while hoping they don't do harm to the economics. it's kinda a shitty situation b/c i also see parallels to what went on in Core.
To be clear, the op codes is not an ABC proposal. Its coming from nChain. I've supported and encouraged their efforts from the beginning. Its therefore uncontroversial in the dev community.
WRT OP_RETURN, we can't stop people from embedding data. Use a 1-of-N multisig and all but one signature is data. So better to have it clearly marked.
And they have to pay the market rate per byte for tx space anyway.
Or do we not believe in market forces here anymore either, instead opting to make decisions a priori about "what's best for bitcoin cash"?
WRT OP_RETURN, we can't stop people from embedding data. Use a 1-of-N multisig and all but one signature is data. So better to have it clearly marked.
And they have to pay the market rate per byte for tx space anyway.
Or do we not believe in market forces here anymore either, instead opting to make decisions a priori about "what's best for bitcoin cash"?
@theZerg
>Where is the "a stripped down non token non altcoin embedded BCH protocol,"
at the very least, it's sitting right in front of you as the existing implementation of BitcoinCash. IOW, if you don't do a thing, i think BCH is headed for success, possibly as the next world reserve currency. and if by hypothecate, you mean loans, it's hard to know how the market will handle that. i'm not concerned about it. how does embedding tokens/altcoins directly into the BCH protocol handle hypothecation?
>Where is the "a stripped down non token non altcoin embedded BCH protocol,"
at the very least, it's sitting right in front of you as the existing implementation of BitcoinCash. IOW, if you don't do a thing, i think BCH is headed for success, possibly as the next world reserve currency. and if by hypothecate, you mean loans, it's hard to know how the market will handle that. i'm not concerned about it. how does embedding tokens/altcoins directly into the BCH protocol handle hypothecation?
Last edited:
Why not split the coin? BCH for everyone who doesn't see the need for opcodes, BCT (Bitcoin Tokenized) for everyone betting on opcodes.
Everyone currently holding is vested in both outcomes.
Everyone currently holding is vested in both outcomes.
I have to be completely honest @cypherdoc, I asked you some very hard questions about you being against tokenization in general, and you respond by avoiding the question, by moving the goalposts (from no tokenization to maybe 2nd layer tokenization) and offer vaporware solutions (with drawbacks that I have many times concretely specified -- in particular lack of SPV wallet support -- a feature even more critical in 2nd and 3rd world countries).
Tokenization has always been part of the "bitcoin-maximalist feature list" (by that I mean what was promised in the talks of 2011 & 2012 when bitcoin was going to be the sole crypto that ate the world). Sure it was colored-coins. But the change to enable SPVable colored coins (OP_GROUP) is tiny compared to the changes required by these other proposals.
Be careful that you do not start using the very argumentation tactics that we despised in Core.
Tokenization has always been part of the "bitcoin-maximalist feature list" (by that I mean what was promised in the talks of 2011 & 2012 when bitcoin was going to be the sole crypto that ate the world). Sure it was colored-coins. But the change to enable SPVable colored coins (OP_GROUP) is tiny compared to the changes required by these other proposals.
Be careful that you do not start using the very argumentation tactics that we despised in Core.
Last edited:
ok, you called me a keyboard troll last week for that backhanded slap about you being an inflationist, which was deserved. now, i'm calling you a keyboard troll back, as nowhere have i said i don't believe in market forces. just the opposite, in fact.
how is you pushing OPGROUP for betting not "opting to make decisions a priori about "what's best for bitcoin cash"?"
[doublepost=1522259537,1522258889][/doublepost]@theZerg
>I have to be completely honest @cypherdoc, I asked you some very hard questions about you being against tokenization in general, and you respond by avoiding the question, by moving the goalposts (from no tokenization to maybe 2nd layer tokenization) and offer vaporware solutions (with drawbacks that I have many times concretely specified -- in particular lack of SPV wallet support -- a feature even more critical in 2nd and 3rd world countries). Be careful that you do not start using the very argumentation tactics that we despised in Core.
it's called concession, not moving goalsposts, which i deserve some credit for. are you conceding?
while we're at it, you called me a troll twice in the past; once last week and the other time when i was the only one around here who advised against implementing the EB/AD/BV/MG/ system in BU b/c i thought it was too complex and hard to explain. now, is that the reason why BU failed? i don't know for sure but i can tell you for sure that i found it very difficult to explain to the outside community. when it became clear to me that you weren't going to listen, i sucked it up like a man and decided to throw my full support behind you. i bet i can lay claim to being your most vocal supporter during the year and a half fight for BU. here, against trolls like @jonny1000, and on reddit and twitter. it was very hard to explain and justify and it failed. it was also specifically attacked by @jonny1000 via his "gating" exploit. i find OPGROUP to be similarly too complex. and i'm not talking about in LOC. i'm talking about macroeconomically. it's a huge bet that intra-protocol token/altcoin embedding will be good for BCH as a currency and veers it's vision off to an Amazon model from simple p2p ecash. at the very least, we should go slow. you're pushing this very hard.
Last edited:
"how is you pushing OPGROUP for betting not "opting to make decisions a priori about "what's best for bitcoin cash"?""
By disallowing a feature, you block the entire market from using it.
By allowing a feature I enable the possibility, but each individual -- the market -- decides whether or not to use it.
This isn't segwit -- I'm not deprecating BCH txns.
So to block OPGROUP you should not just make the argument that its unnecessary, but an even stronger argument that it will be both popular AND simultaneously its popular use will damage Bitcoin Cash. This strikes me as an argument that is fundamentally against the efficient market hypothesis.
Why am I pushing it so hard? Because we are going to lose a huge market. I have no ulterior motive. I won't be making a token company. I have offered the coingeek bounty to BU. At the same time, I have companies telling me that if we don't get a solution they'll be going with a private blockchain or competitor. I don't think we can go slowly. Its likely this year or not at all. And I, and opgroup, haven't introduced the "complexity". colored coins did that years ago.
Now for some reason you are derailing the discussion to go into Emergent Consensus? I don't want to go there right now; we can take that up a different time, but I will tell you that the initial miners adopted BU specifically because EC would have ended block size argument forever, and that the final swing miners (in particular F2Pool) all had significant altcoin mining infrastructure and likely holdings.
And finally, BU didn't fail. Where do you think Bitcoin Cash came from?
By disallowing a feature, you block the entire market from using it.
By allowing a feature I enable the possibility, but each individual -- the market -- decides whether or not to use it.
This isn't segwit -- I'm not deprecating BCH txns.
So to block OPGROUP you should not just make the argument that its unnecessary, but an even stronger argument that it will be both popular AND simultaneously its popular use will damage Bitcoin Cash. This strikes me as an argument that is fundamentally against the efficient market hypothesis.
Why am I pushing it so hard? Because we are going to lose a huge market. I have no ulterior motive. I won't be making a token company. I have offered the coingeek bounty to BU. At the same time, I have companies telling me that if we don't get a solution they'll be going with a private blockchain or competitor. I don't think we can go slowly. Its likely this year or not at all. And I, and opgroup, haven't introduced the "complexity". colored coins did that years ago.
Now for some reason you are derailing the discussion to go into Emergent Consensus? I don't want to go there right now; we can take that up a different time, but I will tell you that the initial miners adopted BU specifically because EC would have ended block size argument forever, and that the final swing miners (in particular F2Pool) all had significant altcoin mining infrastructure and likely holdings.
And finally, BU didn't fail. Where do you think Bitcoin Cash came from?
Last edited:
>By disallowing a feature, you block the entire market from using it.
but to enable it, you have to add a new ruleset (OPGROUP), change tx format, and force all miners and nodes to verify your changes continuously. at least that's how i understand it from @rocks's explanations. this is what core did by forcing miners to accept a 75% discount for their work to enable, guess what, a company profit model. like i said before, open source is about allowing permissionless innovation of good ideas, not bad ideas. now i'm not saying OPGROUP is necessarily a bad idea; it just sounds to me like a significant chunk of the community wants to wait this one out for more testing. and i think they should, esp from a macroeconomic POV.
>This isn't segwit -- I'm not deprecating BCH txns.
true, but if it forces all miners an nodes to carry extra debt then it's debatable whether it has any advantages over OPRETURN whose data can be purged from the UTXO set. i get your idea of wanting SPV wallets to be functional but my bet is that it's easy to establish shared local nodes even for third world countries esp if you believe that financially capable local businesses (who will run full nodes) will want to do commerce with those SPV wallet users, which they will.
>but an even stronger argument that it will be both popular AND simultaneously its popular use will damage Bitcoin Cash.
i thought i was doing that?
>I have no ulterior motive.
i totally believe you. this is a major reason why i've supported your efforts so heavily in the past.
>Now for some reason you are derailing the discussion to go into Emergent Consensus?
no derailment. i was only trying to demonstrate that i supported you heavily in the past despite me initially disagreeing with you, losing the argument, and thinking you have a flair for complexity. i'm sure i can do that again if you convince me that OPGROUP is a good idea. i'm just not convinced yet.
>And finally, BU didn't fail. Where do you think Bitcoin Cash came from?
ok, you can take that position. and then i'll take some credit for it's success too
but to enable it, you have to add a new ruleset (OPGROUP), change tx format, and force all miners and nodes to verify your changes continuously. at least that's how i understand it from @rocks's explanations. this is what core did by forcing miners to accept a 75% discount for their work to enable, guess what, a company profit model. like i said before, open source is about allowing permissionless innovation of good ideas, not bad ideas. now i'm not saying OPGROUP is necessarily a bad idea; it just sounds to me like a significant chunk of the community wants to wait this one out for more testing. and i think they should, esp from a macroeconomic POV.
>This isn't segwit -- I'm not deprecating BCH txns.
true, but if it forces all miners an nodes to carry extra debt then it's debatable whether it has any advantages over OPRETURN whose data can be purged from the UTXO set. i get your idea of wanting SPV wallets to be functional but my bet is that it's easy to establish shared local nodes even for third world countries esp if you believe that financially capable local businesses (who will run full nodes) will want to do commerce with those SPV wallet users, which they will.
>but an even stronger argument that it will be both popular AND simultaneously its popular use will damage Bitcoin Cash.
i thought i was doing that?
>I have no ulterior motive.
i totally believe you. this is a major reason why i've supported your efforts so heavily in the past.
>Now for some reason you are derailing the discussion to go into Emergent Consensus?
no derailment. i was only trying to demonstrate that i supported you heavily in the past despite me initially disagreeing with you, losing the argument, and thinking you have a flair for complexity. i'm sure i can do that again if you convince me that OPGROUP is a good idea. i'm just not convinced yet.
>And finally, BU didn't fail. Where do you think Bitcoin Cash came from?
ok, you can take that position. and then i'll take some credit for it's success too
Last edited:
as an aside and hopefully before anyone starts freaking out about cryptocurrency markets, the general markets are suffering too. liquidity is slowly being removed from the system:
well, @cypherdoc I definitely appreciate the support you've given me and BU over the years. And yes you should definitely take credit for the success of Bitcoin Cash. Building the community in preparation for the HF was a huge part of the preparation. Miners and users didn't magically just "if you build it, they will come". Its no coincidence that BUIP055 was issued soon after the BU China trip...
It actually seems to me like the majority of the community is in support of tokens and op_group which is why I'm quite surprised by this delay. And if you want to see complexity, look, really look at some of the other schemes. For example, just think a bit about what a clusterfuck counterparty's first-come-first-serve token naming scheme will be, when applied to existing securities. And I seriously doubt that anyone has really tried to break the OP_RETURN client validated tokens... a single bug and we'll have an undetectable token chain fork until enough end users get defrauded that somebody does some careful analysis.
Anyway, I can't do it all. Today, as I see the BCH block size barely exceeding 50k for over a month ( https://bitinfocharts.com/comparison/size-bch.html) and coinbase moving to include ERC20, all I can think is "you can lead a horse to water, but you can't make him drink".
It actually seems to me like the majority of the community is in support of tokens and op_group which is why I'm quite surprised by this delay. And if you want to see complexity, look, really look at some of the other schemes. For example, just think a bit about what a clusterfuck counterparty's first-come-first-serve token naming scheme will be, when applied to existing securities. And I seriously doubt that anyone has really tried to break the OP_RETURN client validated tokens... a single bug and we'll have an undetectable token chain fork until enough end users get defrauded that somebody does some careful analysis.
Anyway, I can't do it all. Today, as I see the BCH block size barely exceeding 50k for over a month ( https://bitinfocharts.com/comparison/size-bch.html) and coinbase moving to include ERC20, all I can think is "you can lead a horse to water, but you can't make him drink".
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
Just spitballing, but how about the idea that BCH beats Core to the punch in allowing two-way peg merge mined sidechains a la Drivechain instead of natively supporting metalayer assets? Assuming the security model is acceptable, BCH would become extremely attractive for some project to come specialize on that, being able to completely design everything from the ground up.
well keep pushing your ideas. it isn't over yet. i'm sure i don't fully understand your position. this is the advantage we have of open communication. if your ideas are good, they'll eventually get accepted. there certainly may be potential to OPGROUP. by my estimation, there are a bunch of ppl out there like me who, while seemingly curmudgeonly conservative when it comes to code, are in actuality quite radical in what they want to achieve; ie a new sound money world reserve currency. that's a huge disruptive goal. i, like you, don't have any other agenda or financial conflict other than making the value of my BCH & BTC go UP. i firmly believe that will be achieved by Bitcoin becoming a pure p2p ecash+SOV. we'll see how this plays out.
Last edited:
- Aug 22, 2015
- 1,558
- 4,693
The SV conference was a great event. There has been loads of coverage on twitter, reddit, yours etc, to inform those who couldn't make it. The atmosphere was excellent throughout and reminded old-timers of the first Bitcoin conferences and improve-the-world enthusiasm of the 2012/13 days.
The BU membership was well represented with some 20 attending.
Bitcoin Cash's next hard-fork remains on track, and @deadalnix's presentation gives the high-level roadmap for 2018. His, and all the other presentations are now linked from the conference website.
There was time for a 2-hour meeting about OP_GROUP and OP codes in general. It was well-attended with many developers, including some miners. The meeting was at once productive as well as at times uncomfortable because people were speaking their mind. This is essential and developer face-to-face meetings need to happen more often, at least twice a year. While the 2-weekly conference calls are very helpful, there is more to be had from in-person communications. A big thanks to Joannes Vermorel for chairing the meeting. His knowledge and high-level perspective is a major boost to the BCH development community.
The re-enabled OP codes (including a few revamped improvements from 2009), lay the groundwork for some advanced scripting features. This gives a middle-ground between basic p2p cash and ETH's "smart contract" / tokens capability. It is very good as a first stage. Let's see what the ecosystem can do with what is provided in May. nChain advise that they have already designed some advanced scripts and the community will see these after June 1st.
During the meeting OP_GROUP found both proponents and opponents of native tokens. Some good criticisms were aired, beyond it being "late", concerns which have been mentioned here (@cypherdoc) about the effect and perception of the 21M coin total, also, about meta-data in the UTXO set, about loss of some simplicity in transaction building and processing. These are informed and legitimate concerns, and something which deserve addressing at length. There is a feeling that such concerns can be mitigated, so BU will continue revising OP_GROUP and make it available for developer community testing. Depending upon how the increased OP_RETURN data gets used, and what advanced scripting can actually be done with the new OP codes, will determine the timescale for when or if OP_GROUP is brought back to the table as a consensus change proposal.
The BU membership was well represented with some 20 attending.
Bitcoin Cash's next hard-fork remains on track, and @deadalnix's presentation gives the high-level roadmap for 2018. His, and all the other presentations are now linked from the conference website.
There was time for a 2-hour meeting about OP_GROUP and OP codes in general. It was well-attended with many developers, including some miners. The meeting was at once productive as well as at times uncomfortable because people were speaking their mind. This is essential and developer face-to-face meetings need to happen more often, at least twice a year. While the 2-weekly conference calls are very helpful, there is more to be had from in-person communications. A big thanks to Joannes Vermorel for chairing the meeting. His knowledge and high-level perspective is a major boost to the BCH development community.
The re-enabled OP codes (including a few revamped improvements from 2009), lay the groundwork for some advanced scripting features. This gives a middle-ground between basic p2p cash and ETH's "smart contract" / tokens capability. It is very good as a first stage. Let's see what the ecosystem can do with what is provided in May. nChain advise that they have already designed some advanced scripts and the community will see these after June 1st.
During the meeting OP_GROUP found both proponents and opponents of native tokens. Some good criticisms were aired, beyond it being "late", concerns which have been mentioned here (@cypherdoc) about the effect and perception of the 21M coin total, also, about meta-data in the UTXO set, about loss of some simplicity in transaction building and processing. These are informed and legitimate concerns, and something which deserve addressing at length. There is a feeling that such concerns can be mitigated, so BU will continue revising OP_GROUP and make it available for developer community testing. Depending upon how the increased OP_RETURN data gets used, and what advanced scripting can actually be done with the new OP codes, will determine the timescale for when or if OP_GROUP is brought back to the table as a consensus change proposal.
i don't think so. they'll be priced in dollars. hence the competition for dollars that BCH will face.
Christoph Bergmann
Active Member
@cypherdoc
And again, I can only repeat the importance of doing token consens compatible: Most Ethereum token are initially priced in ETH prices, because ETH is the only / most simple / most liquid methode to buy them. This is because the token perfectly interacts with Ethereum's smart contracts.
And again, I can only repeat the importance of doing token consens compatible: Most Ethereum token are initially priced in ETH prices, because ETH is the only / most simple / most liquid methode to buy them. This is because the token perfectly interacts with Ethereum's smart contracts.
This is a false syllogism.
To highlight the logic error you are making let's consider RBF.
RBF has the characteristics that
1. It is barely used at all
2. Its mere existence in the code weakens the entire system
Segwit is not much better. So see, perhaps the enabled opcodes might be poorly utilized and also a negative with respect to important use cases.
I think that the best "money" is a coin that does money stuff best and doesn't enable non-money uses. The reason for this is that any feature of the token that isn't actually needed in order for it to be "money" represents unnecessary complexity, which itself opens up attack surface and maintenance cost.
I have continually asked politely how enabling these opcodes makes BCH better "money." I have yet to hear even one cogent reply in my estimation. "It will increase the use of the BCH token" is not a satisfactory answer.
The whole point of Bitcoin Cash is that we're building the best peer-to-peer electronic cash system possible.
Now maybe you've answered the question but I didn't understand your answer. So I have to ask again. ELI5 PLS. How does enabling opcodes make BCH function better as peer-to-peer electronic cash, or how does it increase adoption of BCH as peer-to-peer electronic cash. Please be specific. Thank you for taking the time to explain clearly.
So, WRT above by Jessquit, I think a better question is how enabling the OPGROUP op code SPECIFICALLY makes BCH function better as p2p-ecash. As opposed to op-codes in general? I think the prior discussions about the use of on-chain scripting makes bch better money, especially in terms of possible privacy/security solutions. Is this better for limiting/shaping discussion? And then again I think the primary concerns regarding opgroup regardless of functionality are testing/necessity as they could be superfluous post the additional opcodes. Thoughts?
I'll also reiterate that the reality is that hedge funds pump a probable majority of the ICO investment in the form of dollars directly to the founders in exchange for heavily discounted tokens (in dollar terms), which when they reach a certain return price, again in dollars, get dumped. no need for ether, BCH. it's the proverbial tail wagging the dog, dawg.
edit: you know i use those names affectionately, right?
Last edited: