Gold collapsing. Bitcoin UP.

[79b79aa8]

And yet Bitcoin Cash outperforms your planned economy.

that does not pass; to call BSV a planned economy is just double speak. there is a plan, yes, unfolding as announced: a scalable architecture on top of a fixed protocol, for an instrument that can revolutionize global market economy.

look, i am all for BCH succeeding. but i see dev priorities tugging every which way. it seems to me schnorr was added in part because it was a relatively simple upgrade that fits a narrative of constant improvements (aka altcoin jargon), and partly because some devs do not at bottom agree with bitcoin's fundamental design, and would like to change it to something more chaumian. yet for me as a user, in control of funds whose fungibility has never been under threat, why would i want to contaminate my perfectly legitimate and abundantly private transactions with those of who the hell knows? in the interests of someone else's presumed anonymity?

instead of working on "improvements" like that, the brief was to scale, asap. not by lifting the limit, but by systematically removing bottlenecks. that was the BU plan. it got derailed --ahem --, and structures less prepared to withstand pressure assumed control. i am skeptical the linux model is the correct one for a financial context.

 

[Norway]

This guy gets it...

With (your upgraded version of) IBS, it's possible to build the merkle tree candidates for some (the largest) or all the other miners simultaniously to save some time when a block is found.

But I'm not sure if the optimization is needed, as @shilch has proven how fast merkle trees can be built with a cheap GPU.

The huge gain is in the blockstream

 

[freetrader]

Show me where a BCH developer argues differently.

You could have just disproven me by given a link.

But you don't, because your "argument" consists of attributing views to BCH developers which they do not hold.

In other words, you lie and then accuse others of "misstating your argument".

the fud is that the larger the blocksize limit, the easier it is to produce big attack blocks by a malicious big miner to gain an advantage due to perceived network propagation and local processing inefficiencies. so I ask again, where are they?

This might have been Greg Maxwell's argument, it is not a Bitcoin Cash argument you're trying to get refuted.

 

[cypherdoc]

@jtoomim has made this argument many times even in this thread. it originated with pwuille. I don't have to do your home work for you.
[doublepost=1563198699][/doublepost]ok, since you insist with your hypocrisy:

"There are some performance issues that ought to be addressed before we increase the blocksize limit past 32 MB. Currently, it can take up to 190 seconds to propagate a 32 MB block to or from a miner in China using standard open-source software. That is not good -- anything above 20 seconds on a regular basis can screw up the mining incentives in a way that encourages mining pool centralization."
https://www.reddit.com/r/btc/comments/ccwkl3/why_didnt_we_increase_the_block_size_limit_to_128/
[doublepost=1563198859,1563198151][/doublepost]@jtoomim was a small miner and has complained bitterly and repeatedly about this potential purposeful large miner attack to gain an advantage over smaller miners . where the hell you been?

you're a dissembler and people wonder why I consider you a saboteur.

 

[freetrader]

I asked you to show where a BCH developer claims that a bigger BSL makes spamming easier.
Can't do it, can you?

Instead you deliver an unrelated quote which talks about propagation latencies and has nothing to do with the feasibility of spam at bigger block sizes.

You've well exposed the vacuum of your arguments against BCH and its developers.

BCH, and unfortunately BU , is BTC core all over again. you can see it so plainly in the same recycled arguments against raising the blocksize

Bitcoin Cash clients will clear out the technical roadblocks while scaling.
Core just refused to scale based on whatever pretexts they could come up with.
[doublepost=1563199710][/doublepost]

@jtoomim was a small miner and has complained bitterly and repeatedly about this potential purposeful large miner attack to gain an advantage over smaller miners . where the hell you been?

you're a dissembler and people wonder why I consider you a saboteur.

Two ad-homs in one post.
Par for your course.

 

[cypherdoc]

did you cross your eyes so as not to see the slash? to any honest person the slash means "or". and you continue to act as if @jtoomim, who is a BCH dev, has never made this argument. you're even a sorry excuse for a saboteur:

>i keep waiting for my 128MB spam/attack blocks and soon to be 2GB.

 

[cypherdoc]

The argument is that selfish mining is a real phenomenon, and large pools can use their concentrated hashrate to get more block rewards than they deserve based on hashrate alone, and that those effects get especially strong when blocks get larger than the infrastructure and software can quickly process.

here's another example of what i consider utter bullshit from a BCH dev. like i asked before; where are all the 128MB attack blocks on the BSV network by the large miners to drive out the smaller one's? no, the selfish mining theory never made sense and is why it's never been attempted. it would be a short term play at best and would destroy the investment and trust of other miners in the network to the attackers detriment. and others have made great arguments in relation to this also as in, so what if it happens? an "attack" like this should/would force small miners to upgrade fast or perish. it's called competition which apparently BCH devs are against:

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1480#post-94537
[doublepost=1563203169][/doublepost]

hey @freetrader, keep trying to fork this thread will you? aww, not possible. but great to see you have plenty of time for GCBU and not ABC; we like using you as our doormat.

 

[trinoxol]

> This is false. The central belief of Bitcoin Cash is that Bitcoin can scale.

OK, that's true. BCH does believe in on-chain scaling. It seems, that statement of mine was generated by the tribalistic ape software in my brain

@jtoomim has not replied yet. I am looking forward to reading his response.

 

[cypherdoc]

>OK, that's true. BCH does believe in on-chain scaling.

sure, but ABC and it's followers believe the pace of scaling should be determined by devs and their math calculations and/or interests at the time. as if anyone has ever been successfully able to mathematically model human behavior and it's incentives. personally, i consider this latest BCH donation rally to be a major failure as all it did was reinforce to the shitlord that whining works w/o actually scaling the protocol. what do you think he's learned from that? ---> more whining, more stalling, less scaling, MoMoney. wash, rinse, and repeat.

otoh, BSV and it's followers believe in leaving the pace of scaling to market behavior. remove all limits and let the financial incentives go to work. and no, they've never believed that one can mathematically model human behavior and it's incentives. it's more like remove all limitations and get out of the way. the major involved economic players of miners, users, and merchants will figure out what blocksizes to mine, what hard caps to set, and what fees to charge and pay. not devs, who do not get paid by the protocol, who do not invest in the protocol, and who do not mine. some enlightened devs might to do these things but most likely to a pitifully small insignificant degree. and when done in the context of a blocksize cap, which sends the wrong signals to the above major economically involved players, its a non starter that stifles interest from major players and cripples the full expression of Bitcoin and what it was meant to be.

 

[bsdtar]

electron cash 4.0.6 and up has schnorr signatures enabled by default. this is not explicitly announced upon installation. i was absolutely NOT AMUSED about making a transaction and finding out after the fact that i participated in a group signature scheme.

You're possibly conflating schnorr and cashshuffle. Schnorr is currently a simple opt-in replacement for a *single* ECDSA signature. There's no group signature or batching involved. BCH plans to implement batch validation of schnorr signatures, which delivers some performance improvement on signature verifications. BTC OTOH intends to implement schnorr group signatures in order to reduce transaction size and verification time (i.e. one signature for all txn inputs). These are all different monsters.

If your coins in electron cash participated in a group signature scheme, it means *cashshuffle* was enabled. Cashshuffle is the one connecting to a server, finding participants, negotiating and signing a multi-party group transaction.

Anyway, I agree that Cashshuffle shouldn't be enabled by default in electron cash (if it really is).
[doublepost=1563219472][/doublepost]

look, i am all for BCH succeeding. but i see dev priorities tugging every which way. it seems to me schnorr was added in part because it was a relatively simple upgrade that fits a narrative of constant improvements (aka altcoin jargon), and partly because some devs do not at bottom agree with bitcoin's fundamental design, and would like to change it to something more chaumian. yet for me as a user, in control of funds whose fungibility has never been under threat, why would i want to contaminate my perfectly legitimate and abundantly private transactions with those of who the hell knows? in the interests of someone else's presumed anonymity?

And here you blame BCH client devs for an ElectronCash-only feature.

 

[lunar]

"If you're looking to use Bitcoin to go on the Dark Web, and think you're not going to get caught, you're going to get caught. This is a warning, If you want to use it for speculation, that's one thing, if you want to use it for illicit activities, we're going to put the full effort of the US treasury and the regulators onto that"

They're here .....

Businesses that have no AML/CFT are going to be roasted.

 

[bsdtar]

It's rather unfortunate the status of BCH development, but I guess that's what happens with unincentivized open source projects. It seems ABC is in a long backporting spree, bringing their code up to date with bitcoin core. I looked through 5 pages of code submissions in https://reviews.bitcoinabc.org/differential/ and saw nothing related to scaling. The draft spec for the November HF seems to confirm this.

 

[Zarathustra]

"If you're looking to use Bitcoin to go on the Dark Web, and think you're not going to get caught, you're going to get caught. This is a warning, If you want to use it for speculation, that's one thing, if you want to use it for illicit activities, we're going to put the full effort of the US treasury and the regulators onto that"

They're here .....

Businesses that have no AML/CFT are going to be roasted.

No problem. BCH's opinion leaders have a road map:

 

[79b79aa8]

You're possibly conflating schnorr and cashshuffle. Schnorr is currently a simple opt-in replacement for a *single* ECDSA signature. There's no group signature or batching involved. BCH plans to implement batch validation of schnorr signatures, which delivers some performance improvement on signature verifications. BTC OTOH intends to implement schnorr group signatures in order to reduce transaction size and verification time (i.e. one signature for all txn inputs). These are all different monsters.

If your coins in electron cash participated in a group signature scheme, it means *cashshuffle* was enabled. Cashshuffle is the one connecting to a server, finding participants, negotiating and signing a multi-party group transaction.
[doublepost=1563219472][/doublepost]

thank you for the clarification -- this helps. i am talking about schnorr, not cashshuffle. it was not clear to me that different versions existed, for different purposes. i was under the mistaken impression that the sole purpose of schnorr sigs was key aggregation.

And here you blame BCH client devs for an ElectronCash-only feature.

not really. schnorr was the marquee addition of the may 15th BCH upgrade. presumably the intention was for this addition to actually be used -- otherwise what is the point? but it is not reasonable to expect end users to operate a full client. electroncash, a leading light client, implemented schnorr by default.

but now i understand why the ABC BCH roadmap would claim schnorr sigs are part of the scaling plan. it is a feeble gesture towards scalability. a small performance improvement that requires a hard fork to deploy is not getting BCH anywhere near the goal, i.e. that for which BCH split from BTC in the first place.

 

[cbeast]

This seems to be a way to do betting when an oracle provides an outcome. This scheme works inside of a single transaction.

If you want to make an on-chain chess game where two adversaries can only play valid moves and the winner takes the money BSV can't do it. BCH can, BTC can't.

Instead of an oracle, why not use a payment channel to loop the data back into the game? This ensures that the script enforces the rules and also the moves propagate solely within the network. That's what CSW has been talking about with BitCoin being Turing Complete. It also creates an on chain financial incentive for the outcome rather some dubious "oracle" scheme.

 

[lunar]

Outstanding @Christoph Bergmann

Incredible watching all these little pieces come together so fast. Bookmarking on Metanet, this idea couldn't have come soon enough.


Introducing MetaHandles: Making onchain content accessible

 

[trinoxol]

Instead of an oracle, why not use a payment channel to loop the data back into the game? This ensures that the script enforces the rules and also the moves propagate solely within the network. That's what CSW has been talking about with BitCoin being Turing Complete. It also creates an on chain financial incentive for the outcome rather some dubious "oracle" scheme.

That certainly works but it requires all participants to cooperate. It's not enforced by the chain.

I guess you could create an incentive to keep running the game by making both sides stake money and lose it after a certain time period. This would be similar to the way LN penalizes fraud.

In this case, there would be no point in the script enforcing the game rules, right? The participants can enforce them when they build the next state.

 

[cbeast]

@trinoxol Of course it requires an economic incentive, but it is still enforced by the chain. The counterparties only pay a "gas" type fee (probably dust). That's why BSV isn't politburo. In this case the counterparty is a peer rather than the possibility of a "Justice Transaction."

 

[torusJKL]

Outstanding @Christoph Bergmann

Incredible watching all these little pieces come together so fast. Bookmarking on Metanet, this idea couldn't have come soon enough.


Introducing MetaHandles: Making onchain content accessible

Interestingly we have now two solutions that have the same goal but a different approach.

MetHandle uses hashes and encryption to keep the handles and information obscure.
SymRe stores everything in clear text but allows for signing data so that everyone can have his own namespace.

I'm very interested to know if people will use them and what features they prefer.

Both projects are only possible because the limits have been lifted on BSV.

Btw. here is my announcement for the SymRe upgrade.

 

[Norway]

@Christoph Bergmann
You're a developer. Please come out of the closet. We all know now