Gold collapsing. Bitcoin UP.

[jessquit]

adoption

I suppose this was an attempt answer to my question. I find it dissatisfying.

How does "adopting a token for non peer-to-peer cash use" advance the cause of "adopting the token for peer-to-peer cash use?"

If we use the chain to store music files will that also increase peer-to-peer cash usage?

Honest questions. Sorry if they've been asked and answered before to everyone else's satisfaction.

 

[hodl]

@hodl: Good points. You are conservative regarding changes for good reason.

So I guess I stick with my opinion that it is better to let it stew a bit longer. In general, I think we shouldn't be chasing the latest fads, be it ICO or anything, with BCH

It's also about watching the trends. By my estimation, BCH was successful merely by extending the blocksize. It latched onto the big block community vision in tandem with the precoded UAHF from Bitmain. The sentiment was so strong to get away from an entrenched Bcore that was pushing the community towards its own profit driven agenda that we all had pegged from the outset here on this thread which resulted in widespread banning and censorship. There was never any promise of re-enabling OP CODES or smart contracting. Just a 1 to 8mb see increase which resulted in the resounding success of BCH in its current form. This all happened just 4m ago. @deadalnix was a nobody who's coding expertise was totally an X factor ; that's how extreme the sentiment was just for bigger blocks.

Now, out of the blue, we're told we are going to be force fed all these codes including OP GROUP, that I throw into the same category. Imo, the new dominant implementation will be the one that suspends this drama until these issues get sorted out via community discussion and simply implements a 8 to 32mb blocksize increase.
[doublepost=1519494427][/doublepost]

I suppose this was an attempt answer to my question. I find it dissatisfying.

How does "adopting a token for non peer-to-peer cash use" advance the cause of "adopting the token for peer-to-peer cash use?"

If we use the chain to store music files will that also increase peer-to-peer cash usage?

Honest questions. Sorry if they've been asked and answered before to everyone else's satisfaction.

It doesn't. Smart contacts are a first world problem. The third world is who's going to drive BCH adoption ultimately.

For all the speculative OP CODE projects, we have stocks, bonds, and insurance contracts already that serve those purposes just fine right now. Yes those require centralized entities to mediate legal disputes, it could be argued.

 

[awemany]

@hodl: I think you make great points. I don't know whether I'd say 'force fed', though. I think what is happening is that a subset of the community is more eager to try new stuff and, given the nature of things,
BCH got some inertia also in 'going forward' which many people interpret as 'lets do new stuff'.

And I totally hear you. I might be just a notch more open to changes than you are, but I also like to keep things going at a slow pace.

I don't see a clear reason yet that any of the opcodes will do irreparable harm down the road, but why even risk it now! (Also @Tom Zander )

We have a set of rules that work well for the most part. With tweaks to the size of data after OP_RETURN (or so I heard, correct me if I am wrong), folks like /u/Insette from reddit can try to run their Counterparty stuff on the chain. I am not really sure it will help anything, but given that stuff like this has been tried in the past (Mastercoin etc.), I don't think it will do harm, either. Also, that would be a change that would just allow what is possible already anyways (put data onto the chain), just with more involved/contrived mechanisms to store the bits.

@jessquit: Welcome to the forum. As I said above, I don't think we need them. IMO, there's a fine line between slowly evolving the protocol as necessary and chasing fads.

This goes both for the deactivated opcodes as well as the new OP_GROUP one. Let's just be careful.

I personally think getting the software we have now, with the rule set we have now to a state where it is really smooth and nice and usable and with low bug count makes a lot more sense than further quick tweaks to the consensus rules.

Thinks that I think make sense in terms of development:

- making it more CPU efficient and/or parallelize (e.g. ParVar from ptschip and the giganet changes from thezerg et all)
- making it more network efficient (graphene, xthin, ...)
- making it less bursty (weakblocks )
- cleaning up the code and modularizing it: I think it would be great if bitcoind evolves into an interconnected set of nice and small and scope-limited daemons as separate processes talking to each other.

I spent my time debugging my code within the multi-threaded beast that is bitcoind the last couple days, in the context of weakblocks. It is one hairy mess IMO (and that's not directed at any particular Satoshi-code-derived implementation). Let's rather fix that!

 

[jessquit]

Smart contacts are a first world problem. The third world is who's going to drive BCH adoption ultimately.

Agree. The chain is permissionless but we should be focusing on cash-usage adoption.

It's Bitcoin: a Peer-to-Peer Electronic CASH System. Isn't that what we've been repeating on r/btc for the last two, three years now? "Bitcoin: a Peer-to-Peer Electronic CASH System" Not: "Bitcoin: a Peer-to-Peer Electronic CONTRACT System"

Again I'm sorry for being a johnny-come-lately to this forum and I don't mean to drop a turd in the punchbowl, sorry if it feels like I'm stirring the pot.
[doublepost=1519495156][/doublepost]@awemany

Thinks that I think make sense in terms of development:

- making it more CPU efficient and/or parallelize (e.g. ParVar from ptschip and the giganet changes from thezerg et all)
- making it more network efficient (graphene, xthin, ...)
- making it less bursty (weakblocks )
- cleaning up the code and modularizing it: I think it would be great if bitcoind evolves into an interconnected set of nice and small and scope-limited daemons as separate processes talking to each other.

I spent my time debugging my code within the multi-threaded beast that is bitcoind the last couple days, in the context of weakblocks. It is one hairy mess IMO (and that's not directed at any particular Satoshi-code-derived implementation). Let's rather fix that!

ACK ACK ACK ACK ACK ACK

Couldn't possibly say it better myself. Carry on.

Edit: still figuring out the syntax on this board lol

 

[bitsko]

I suppose this was an attempt answer to my question. I find it dissatisfying.

How does "adopting a token for non peer-to-peer cash use" advance the cause of "adopting the token for peer-to-peer cash use?"

it's understandable, the answer was lacking. anything that draws attention to and distributes the peer to peer cash into the hands of more people is beneficial.

'dilution' -yeah, maybe. your thoughts around this are interesting, and it's an open question if a colored coin implementation that needs a 'gas' or it's own token is similar to bi-metalism, and if it is such an inferior way to do it as to make a difference...

I'd love a good economist to break down the differences for sure.

I'm still in favor of an 'all the things' approach, because in order to be the best it should be the most widely used, and if it's not on this platform it will be somewhere else.
[doublepost=1519495724][/doublepost]-I've read some saying this thing must be major in 8...10 years or else it will lose inertia and become ever harder to make it there. my thinking is 2020 or bust.

can we get there by restricting the capabilities of the platform outside of its original scope?

are we half hal, half satoshi with our approach? not quite gold but nothing else except cash? satoshi was 'all the things' imo, and rightly so. adoption.

 

[hodl]

@awemany the way Amaury is going about this smells like Bcore unilaterally introducing changes without any feedback from the broader non dev market participants. I appreciate his attempts to lead as I posted about a few weeks ago but there just hasn't been any attempts to discuss potential negatives. I'm not going to entrench myself in this opinion though as I can see possible needs for these OP codes in the future but today feels too early since BCH hasn't unseated btc just yet.

As for counterparty, the more I think about it the more I'm having difficulty distinguishing it from a sidechain enabled sidecoin in terms of XCP that will compete for fiat investment that I'd rather see go directly into BCH. Don't they more broadly have the same economic effects? The data gets embedded in OP RETURN vs a p2sh redeem script. As I said above, I really don't like the idea of removing satoshis from circulation to do this.

 

[awemany]

Again I'm sorry for being a johnny-come-lately to this forum and I don't mean to drop a turd in the punchbowl, sorry if it feels like I'm stirring the pot.

Don't worry, it is all fine. This thread in particular evolved into a set of regulars discussing and bantering about all kinds of things, some quite loosely connected to or even disconnected from Bitcoin, I guess it is kind of like the "Bitcoin Unlimited main meeting place".

@bitsko: I see two factions getting somewhat angry at each regarding the path forward mainly on the issue of allowing on-chain tokens. I am not arguing to stall now and make this a repeat of the blocksize debate, however:

a) BCH functions as sound money without further changes on that front
b) in retrospective, in the blocksize debate, it took a while for the fronts and arguments to appear more clearly, a couple months maybe

And I think waiting for that clearness by folks debating the respective merits of each approach is the least we should do before we upgrade the consensus rules IMO. I won't personally start a "Bitcoin Cash Gold" (or whatever) fork if I feel my objections are not taken serious. Of course I'll follow along.

I just argue the way I do because I honestly believe stability and being boring and conservative with money is a virtue.

 

[hodl]

Isn't that what we've been repeating on r/btc for the last two, three years now?

Not only there but mostly here since the genesis of this thread 7y ago. Your not dropping any new turds. In fact, from reading all your great posts on reddit, I would have sworn you were one of us just with another name

 

[awemany]

@hodl: I absolutely agree that ABC is too dominant at the moment.

On Counterparty, you might be right. It was my impression that you would still go and lock up the underlying token (so BCH) in your smart contracts.

I see most of the smart contract field as a huge playground with little real applications - and consequently, I see it about as harmless in terms of competition to sound money.

Regarding throwing money away: Can you see more of 10% of the supply being burned by stuff like this?

I honestly can't at this stage and I think it is even less likely in the future. And that's also why I am not worried. And I think in terms of economic impact of divisibility, I see that only if the money supply is changed by orders of magnitude (factor 10 or so).

I can emotionally understand that argument: It just feels wrong to throw stuff away forever. But when thinking it through, I think it is not a problem (anymore).

 

[hodl]

I know my views often border on being curmudgeonly. But as I've said a thousand times, the Big Kahuna is Sound Money. Imo, Bitcoin is a dart pointed at the heart of Central banking. If it only did that, and maybe because it only tries to do that, the price of a single coin will exceed your wildest imaginations. The Forex is the biggest market in the world by orders of magnitude. Slice a big chunk of that off into Bitcoin and the price will skyrocket. Or, better yet, monetize the entire fiat monetary base along with its debt mountain into Bitcoin as the new world reserve currency and boom. You can tell, for sure, this is the ONE function that all the banking interests are most concerned about and that they are actively trying to prevent. Why would anyone but some devs want to divert from that?

 

[Tom Zander]

Imo, the new dominant implementation will be the one that suspends this drama until these issues get sorted out via community discussion and simply implements a 8 to 32mb blocksize increase.

Well, that's not a really hard thing to do. Did that some time ago; https://github.com/floweethehub/hub/blob/master/libs/utils/SettingsDefaults.h#L41

Thinks that I think make sense in terms of development:

- making it more CPU efficient and/or parallelize (e.g. ParVar from ptschip and the giganet changes from thezerg et all)
- making it more network efficient (graphene, xthin, ...)
- making it less bursty (weakblocks )
- cleaning up the code and modularizing it: I think it would be great if bitcoind evolves into an interconnected set of nice and small and scope-limited daemons as separate processes talking to each other.

I spent my time debugging my code within the multi-threaded beast that is bitcoind the last couple days, in the context of weakblocks. It is one hairy mess IMO (and that's not directed at any particular Satoshi-code-derived implementation). Let's rather fix that!

Different people can solve different problems in parallel. The new opcodes open new markets which have seen enormous growth. It makes no sense to let that slip away because some other problems other people are working on should be finished first.

The issues you list have been on the task list for me for a long time and half of them have actually already been fixed in Flowee, the separate processes (or different machines, if you want) design has been implemented and is being used right now.

Apart from suggesting that you try to look at Flowee, please think about the idea that the development of BCH can be done in parallel. Different groups focus on different ideas. At the same time. Ideally those groups don't fight each other but instead just copy paste or implement a spec another group finalized.

 

[freetrader]

p.s. I confirmed that @jessquit is /u/jessquit.

I just thought it prudent given that this forum and thread has seem some games being played in the past.

 

[jessquit]

anything that draws attention to and distributes the peer to peer cash into the hands of more people is beneficial

If you create a non Cash token by burning the cash then the thing you're distributing isn't cash. It's more than a semantic difference.

I view this as some sort of nonmonetary application of pennies. You could take a penny, which itself is "noncounterfeitable", and mark it with a superimposed, additional noncounterfeitable mark, and turn it into a car wash token. Maybe you can do this more cheaply and efficiently than making a brand new car wash token, and maybe it functions better, too. And maybe this increases aggregate demand for pennies as car washes everywhere switch from custom tokens to penny based tokens. But I can't see how it helps increase the CASH use case of pennies or any other denomination.

 

[Dusty]

And maybe this increases aggregate demand for pennies as car washes everywhere switch from custom tokens to penny based tokens. But I can't see how it helps increase the CASH use case of pennies or any other denomination.

More pennies used for tokens -> less pennies around -> higher pennies denomination in fiat.

And what we know from experience is that higher value of a coin is, by far, the more important quality to gain adoption.

So, in my opinion every and each idea that helps grow BCH value directly or indirectly, should be welcomed, supported, and encouraged.

[EDIT: spelling]

 

[jessquit]

@Dusty as long as no changes are made that degrade the usefulness of pennies to serve their monetary function in order to make them better serve nonmonetary functions then I might agree with you. There fact that there exists these dual, potentially conflicting goals concerns me however. Most good strategy is based on being the best at A thing, not being the best at MANY things, for this exact reason.

I appreciate the viewpoint however and it is not lost on me.

I think economists might argue a different point, and that is one day we want ito coin to find a stable value and become a widely used unit of account. It is well understood that for the purpose of being a unit of account, it is disadvantages if the money has other purposes. For example, consider gold. Imagine it is the world currency and all prices are stated in gold ounces. Now one day a new industrial use of gold is found. Suddenly the price of peanut butter drops.... You don't want your money to change in value like that.

 

[Dusty]

we want ito coin to find a stable value and become a widely used unit of account

You can't force that unless you are a State (and also in that case, that would not be perfect, as we know).

The good news is that it is totally automatic and unavoidable: as soon as a coin becomes the most widely used mean of exchange in the world, it becomes as stable as it is possible (and way stabler than any currency we have ever witnessed).

 

[jessquit]

@Dusty yes, I agree that our priority is to become widely used as a medium-of-exchange, which is why I personally find zero priority in not-medium-of-exchange use cases like colored coins. Again, sorry if I'm missing something obvious.

 

[bitsko]

'store of value first, cash later

is this markedly different than 'cash first, other things later

I said then, if it's not useable it's less likely to be a store of value.

If you create a non Cash token by burning the cash then the thing you're distributing isn't cash. It's more than a semantic difference.

I view this as some sort of nonmonetary application of pennies. You could take a penny, which itself is "noncounterfeitable", and mark it with a superimposed, additional noncounterfeitable mark, and turn it into a car wash token. Maybe you can do this more cheaply and efficiently than making a brand new car wash token, and maybe it functions better, too. And maybe this increases aggregate demand for pennies as car washes everywhere switch from custom tokens to penny based tokens. But I can't see how it helps increase the CASH use case of pennies or any other denomination.

I agree, it does nothing directly. I suppose if the penny you make a necklace out of is a penny you didn't know about before, and you needed a wallet or bank you didn't have before to own it, it would at least make one aware of that different kind of penny, and give them an account at that different bank(bch).

I think it's a given if something is scarce and some is destroyed, the rest ends up being worth more... so by that metric, coin burning is good for BCH investors.

the question remains are xcp investors detrimental to btc investors. I asked derose hopefully he has some input, was community director for xcp.
[doublepost=1519505294][/doublepost]make note if it's an xcp airdrop those coins were already burnt. the details of what blockfreight is doing haven't been released yet I don't think
[doublepost=1519505837,1519505223][/doublepost]i speculate that if julian(blockfreight) went to the trouble of creating a legal structure to avoid lawsuits related to 'airdrop or burn' it is because he doesn't wish to include the prior pepecash/art community... no one would sue if it was explicitly an airdrop

 

[Dusty]

@Dusty yes, I agree that our priority is to become widely used as a medium-of-exchange, which is why I personally find zero priority in not-medium-of-exchange use cases like colored coins. Again, sorry if I'm missing something obvious.

I think it's useful to study what happened to ethereum: since it became a good platform to issue tokens for ICOs this led a whole lot of users to buy eth to, in turn, buy tokens (they are easily automatically traded with native contracts), and that in turn gave a HUGE boost to the ethereum network, both in users, ideas, code and infrastructure.

It's a really great pity we missed all that in Bitcoin.

 

[awemany]

Different people can solve different problems in parallel. The new opcodes open new markets which have seen enormous growth.

That is a very generic statement. Both in terms of "new opcodes" as well as "enormous growth". I think we should all fully refrain from this kinds of sales pitch talk and boil it down to the details.

What can be enabled with which colored coin proposal? What would opcode #xyz do?

And to me, that honestly quickly becomes quite hand-wavy.

Like I suspect @hodl does as well, I don't see much value in the ICO craze.

Now, I do understand that miners want to process many transactions so there is that and I obviously do support them doing so, as they secure my coins.

As much as I don't see the reason to have Counterparty, their use case is already possible on the chain, correct? All they want is some larger OP_RETURN space, correct?

If I need to choose between different things to do, I rather adjust a constant like the 80 byte OP_RETURN limit than introduce new features.

Given that I can already spread data across multiple OP_RETURNs, that seems like a change with manageable risk.

Also by just adjusting a value, you don't really introduce complexity, especially if you relax it and old transactions validate with new rules. See also the blocksize limit.

It makes no sense to let that slip away because some other problems other people are working on should be finished first.

There is also a difference: I have a validation kernel now for transactions and that grows with all new rules that I introduce. And I cannot ever reduce this complexity again, it impacts the whole network and there's strong economic incentives to keep every bell and whistle that has ever been introduced.

I can however, separate the transaction kernel and the mempool and the network layer from each other and thus simplify debugging each thing.

The issues you list have been on the task list for me for a long time and half of them have actually already been fixed in Flowee, the separate processes (or different machines, if you want) design has been implemented and is being used right now.

That's great and I'll certainly have a closer look at some point again. Do you have comprehensive documentation for your changes?
Last I looked, I didn't find that quickly, so that kind of kept me from looking further. If you do, and they are not easy to find, I suggest to make that so. If they don't exist, well that's the issue I'd have with it right now

I should also say that license issues will keep me from basing any work on your code. If weakblocks turn out to be helpful, I can make a PR for your code. But it becomes very messy license-wise if I would start developing on Flowee and then merge back into BU, for example.
Note that I am not arguing you shouldn't do what you do - I just think that there is - especially with multiple implementations - good reason to stick with developing on MIT-licensed clients first. Unless all clients would chose the license of your client, which I find to be highly unlikely.

Apart from suggesting that you try to look at Flowee, please think about the idea that the development of BCH can be done in parallel. Different groups focus on different ideas. At the same time. Ideally those groups don't fight each other but instead just copy paste or implement a spec another group finalized.

Yes, but see above regarding copy'n'paste & licensing.