Gold collapsing. Bitcoin UP.

[Norway]

We are still dicussing number 1 on your list, @freetrader. We have to get to the bottom of this before we move on to number 2.

I'm seriously looking forward to read how you try to make a case for cross chain atomic swaps with Diffie Hellman signature schemes when the (clever) concept is based on hashlocks and timelocks.
[doublepost=1541126071][/doublepost]

From my perspective it really only matters if it's true or not. You have not commented on that as you have not replied to @deadalnix .

I didn't repy to @deadalnix. I reply to you.

Do you think @deadalnix' point of math being old is good or bad?
[doublepost=1541126295,1541125541][/doublepost]

My view is that if it's more limited than CDS I think it would be bad to reject CDS - unless you can show that your proposal is not more limited (i.e. show how it can solve the other use cases).

So you are open to any protocol change if it's doing something?

If I accused you of being agenda driven, what would be your response?

 

[freetrader]

I'm seriously looking forward to read how you try to make a case for cross chain atomic swaps with Diffie Hellman signature schemes when the (clever) concept is based on hashlocks and timelocks.

I didn't propose that, nor do I know what you mean by "Diffie Hellman signature schemes". Did you mean a DH key exchange? DH over Bitcoin has been done in 2015. If you want I can provide you a link.
If you mean ECDSA, your comment might make more sense to me at the moment, at least that relates to CDS/-V.

Do you think @deadalnix' point of math being old is good or bad?

Deadalnix kindly pointed you to something both Bakketun and you seemed unaware of, but you failed to acknowledge it. Do you dispute it?
And you avoid answering the (imo main) point of limitations raised by deadalnix, a point I'm sure he considers more relevant than the name or age.
Don't fall into the ProfFaustian trap of claiming that something is new when it is old. Even if Bakketun & yourself came up with it independently, if someone else proposed this before then it's right to acknowledge it.

So you are open to any protocol change if it's doing something?

Can you show me how you infer that from anything I've written?
The sentence you quoted should be clear enough and does not give license to "implement any protocol change" at all. This all seems too much like trolling.

If I accused you of being agenda driven, what would be your response?

Everyone has an agenda. Nothing new. Whose agenda do you think I represent and why?

 

[Norway]

If you mean ECDSA, your comment might make more sense to me at the moment, at least that relates to CDS/-V.

Of course I do. Stop nitpicking and give me a important, relevant usecase for OP_CHECKDATASIG.

Deadalnix kindly pointed you to something both Bakketun and you seemed unaware of, but you failed to acknowledge it. Do you dispute it?

What did he "kindly" point out to us? That math is old, and everything has been done before?

I don't in any way dispute that I didn't invent hashes or using them as a way to provide signatures. But I oppose people who put less value to systems like these because they have age.

And you avoid answering the (imo main) point of limitations raised by deadalnix, a point I'm sure he considers more relevant than the name or age.

I have no idea of what you are talking about. Citation needed.

Can you show me how you infer that from anything I've written?

Yes. It's a response to your quote where you imply that a protocol change should happen because my workaround of OP_CHECKDATASIG might not cover possible usecases that you can not describe:

My view is that if it's more limited than CDS I think it would be bad to reject CDS - unless you can show that your proposal is not more limited (i.e. show how it can solve the other use cases).

The onus should be on the party that wants to change the protocol, right?

Everyone has an agenda. Nothing new. Whose agenda do you think I represent and why?

The point isn't that you have a motive, but that you're not interested in learning by having a dialogue. Would you argue with a TV commercial?

 

[freetrader]

I have no idea of what you are talking about. Citation needed.

"It's also significantly more limited." - deadalnix

You literally copied the sentence directly before that one and omitted it.
You wanted to discuss point (1) your oracle solution, deeply. Well then, I'll wait for you to tell me when you or Bakketun have addressed the challenges posed in the Reddit thread.

you imply that a protocol change should happen because my workaround of OP_CHECKDATASIG might not cover possible usecases that you can not describe

Those use cases, like forfeit transactions etc., have not been rebutted. They, and CDS/-V, appear very solid in terms of benefits going beyond oracles or ACCTs.
I don't know if any of those other use cases can already be satisfied by convoluted scripts.
It is possible. Is it desirable to delay these use cases for Bitcoin Cash until someone figures it out in months or years, when we could have them as soon as people have CDS-/V ? It doesn't seem smart to me to delay this utility by an undefined amount of time. It will only cost Bitcoin Cash in adoption.

If your lengthy scripts without CDS are more favored by the miners, just write them and miners should prefer to mine them. Economic incentives, right?

The onus should be on the party that wants to change the protocol, right?

Several beneficial use cases have been shown so far. It's up to miners now - if they don't feel it's enough then they simply won't run clients that implement it.

 

[Norway]

"It's also significantly more limited." - deadalnix

Jeez, @deadalnix' unfounded assertion is your source. Think for yourself.

Those use cases, like forfeit transactions etc., have not been rebutted.

Hold your horses,we're not going down your list yet, but we'll get there.

You have to defend your top point first, oracle bets, or admit my method makes OP_CHECKDATASIG moot in this context. Give me an example.

If your lengthy scripts without CDS are more favored by the miners, just write them and miners should prefer to mine them. Economic incentives, right?

Is this script "lengthy" to you? It's pretty short & sweet in my book:

Several beneficial use cases have been shown so far.

No. You haven't even provided a good case for your top reason yet.

 

[awemany]

I was positive to OP_CHECKDATASIG until I started to investigate the need for this OP-code myself and discovered that the new features advertised can be done with the current script protocol. I'd like to get some feedback from BU devs on this, but so far it's just crickets gallore on that front.

I actually pointed out to you that CDS will enable ZCF - which you brushed off as 'not important'. But that is quite different from "crickets galore".

 

[Epilido]

Jeez, Think for yourself.

When you find that no one is listering to you or helping with your ideas, look back at your recent tone.

 

[cypherdoc]

this looks terrible:

 

[cypherdoc]

otoh, this looks great:

 

[Bagatell]

@cypherdoc I don't see anything..


f5 did it

 

[Jonathan Vaage]

This doesn't look so good either. Can't see it in this chart but there was no rebound at all after the last BTC difficulty drop.

 

[79b79aa8]

Clearly not able to go near 128MB at this stage, despite the massive humdrum on social media.
False advertising imo, and we need to point it out as it could otherwise damage the reputation of the coin if in November this becomes the main client and the first thing a stress test (planned for 17 Nov with 24M transactions over 24 hours, that would require > 32MB sustained blocks) will show that hashpower "put in charge" an implementation which does not deliver on its main feature.

for those still not paying attention: there will be an attempt to send 1M tx/ hour for 24 hours on nov. 17. the activity yesterday was a preliminary test of the system to be used. it works. remember that batches of transactions can be sold as reasonably priced advertising.

https://playbch.cash/index.html > professional stress test.

or follow the action on memo.


EDIT: congratulations BU for being the best performing implementation during yesterday's blasting.

 

[Norway]

I actually pointed out to you that CDS will enable ZCF - which you brushed off as 'not important'. But that is quite different from "crickets galore".

Yes, it's true that you pointed out that CDS will enable ZCF. I said ZCF is clever, but I don't think zero-conf is an unsolved problem (we have had bitcoin ATM's for many years now), and that I don't think ZCF is a good enough reason to change the protocol.
[doublepost=1541203405,1541202749][/doublepost]

 

[Otaci]

ZCF is clever but terrible PR.

"I need $15 in my wallet to buy a $5 coffee? Because the payment system is not reliable? WTF"

 

[Norway]

@Otaci
ZCF is being used as a reason for OP_CHECKDATASIG after I showed how easy oracle bets can be done with the current protocol.

ABC are also giving cross chain atomic swaps as a reason for OP_CHECKDATASIG, but AFAIK, this can also be done with hash locks and time locks. Is that your impression too?

https://hackernoon.com/atomic-swaps-simply-explained-how-to-swap-cryptocurrencies-without-a-middleman-6cd29680c32e

 

[Roy Badami]

Double check my math, but at nominal ~25% hashpower (according to Coin Dance) the likelihood of 6-in-a-row for CoinGeek's pool is ~ 0.024%.

The probability of 6 consecutive blocks being mined starting at exactly block 554312 is indeed 0.25^6 = 0.024% (assuming 25% hash rate). So if CoinGeek had announced in advance "We will mine a 6 block run starting at block 554312" then there would indeed be a probability of 0.024% of them achieving their goal by pure chance.

But that's not very interesting since (I assume) we're more interested in the probability of CoinGeek getting a run of 6 at all, rather than a run of 6 starting at one particular block number. It turns out that the maths for this is actually surprisingly complicated, but conveniently there happens to be a web site with a JavaScript calculator that solves this exact problem.

http://maxgriffin.net/CalcStreaks.shtml

So if we plug in N=144, K=6, p=0.25, we get that the probability of CoinGeek mining 6-in-a-row on any particular day (144 blocks) is 2.5%. Setting N=1008, we see that the probability of it happening in any given week is 16.8%

 

[Norway]

We are 12 days from november 15. Correct me if I'm wrong, but the latest BU release doesn't support the SV rule set. Will there be a release that supports SV before november 15? If so, when?

 

[Bagatell]

@lunar

Given CSWs recent tweet storm and the Reddit reaction to it I'm liking our bet more now.

 

[Christoph Bergmann]

ZCF is clever but terrible PR.

"I need $15 in my wallet to buy a $5 coffee? Because the payment system is not reliable? WTF"

to be honest, 0conf is not a problem of coffee-payments, but of exchanges, gambling and ATMs. Here ZCF could indeed help against competing with Lightning, Dashpay or fast ETH confirmations ...

But to agree with you and @Norway: I don't see so much further reasons why DSV needed. When BCH was created, it was not because "Bitcoin Core does not support oracles, we need to fork". Like it was not "Bitcoin Core has Topological Transaction Ordering, we need to fork!".

It was rather "Bitcoin Core is controlled by a centralized development comittee, we need to fork." Unfortunately, it seems we just changed Core for ABC -- and we just changed Roger Ver against CSW as the villain to deflect from the real centralized control.
[doublepost=1541264126][/doublepost]

We are 12 days from november 15. Correct me if I'm wrong, but the latest BU release doesn't support the SV rule set. Will there be a release that supports SV before november 15? If so, when?

Maybe some ABC developers briefed some BU seniors to exclude it :/

Edit: To be fair, BU developers started with implementing ABC changes, because they assume that ABC will have majority and thus default on it to not risk a chain-split. But I agree, SV should be an option, especially since SV fork is much more closer to BU membership votes than ABC fork.

 

[Norway]

Got this response from @solex on Slack:

The new release is imminent. There is no deliberate delay or "strategy" to affect miner choice. They should have enough time to deploy it.