Gold collapsing. Bitcoin UP.

[Norway]

the fraudulent tx is easy to detect, but that's not the one the defrauded party sees. time between txs is not the main factor for success.

This doesn't make any sense to me. I assume a wallet/POS product for shops etc will do a doublespend check by polling a number of nodes around the earth for doublespend attempts if a single node have trouble detecting this.

If it's this easy to detect doublespends and alert the merchant whithin a 2-5 seconds window, I would say the problem is solved.

 

[Norway]

This is lifted straight from CSW's catch-phrase book. Locking the protocol (after removing the block limit) might have made sense when Bitcoin had 95% of the cryptocurrency market.

It still makes sense to be predictable. Gemini postponed the listing of BCH because of the november shitshow.

 

[lunar]

This is lifted straight from CSW's catch-phrase book. Locking the protocol (after removing the block limit) might have made sense when Bitcoin had 95% of the cryptocurrency market. It has been crippled since and now many other coins are competing.

The first person I remember talking about this was Andreas A. 'Protocol ossification'. It's a key function of sound money. Stable, predictable and reliable. I fully admit there are a few things that still need changing (mainly uncapping the blocksize and other limits removed, like opcode limits and max/min Tx sizes) We must create a free market for blockspace and get the protocol to a place where it doesn't require changing (apart from bug fix) This is TCP/IP not Linux.

Right now is Fidelity effect round two, big companies with millions of Txs need room to move. All they see is warring parties arguing over what to add and change. The perfect really has become the enemy of 'Good enough'.

I see the potential for BU to be subverted, with 2+ coding members now publicly stating Nakamoto consensus doesn't work. (probably because they can't get their own way)

Anyway, this has been rehashed ad nauseam. Beer o'clock.

 

[lunar]

 

[VeritasSapere]

I figured you guys would appreciate this.

 

[Norway]

Ryan is right about many things but not about this. He paints 1MB transactions as an alternative to DSV. Well, those are huge, and a very costly barrier against useful functionality such as trusted oracles. I am not saying that all oracles can be trusted, but there are many situations where it could theoretically work, especially where major companies are signing data. There is a great discussion here which gives a flavour of the pros and cons.

Yes, 1MB transactions sounds ridiculous for this function. Is BU working with nChain on bringing bignum back?

 

[Mengerian]

What's the point of these scenarios? Everyone agrees that we need to massively scale, and have a high volume of transactions to make up for the block reward over time. This is not a new insight, or unique to nChain. And changing a number from "32" to "128" won't magically make it happen.

BU and ABC are aiming for massive blocks - Gigabyte and bigger. They are doing technical work to make the software handle bigger blocks, and laying the groundwork for scaling well into the future.

It still makes sense to be predictable. Gemini postponed the listing of BCH because of the november shitshow.

Yeah, predicatability is very important. That's why BU, ABC, and others were all trying to stick to a predictable upgrade schedule. Over time, they could become less frequent as the protocol becomes mature and ossifies. Each upgrade is meant to be a manageable change, with releases made well in advance so people have time to upgrade. Then nChain came along and threw everything into chaos and uncertainty.

 

[Richy_T]

players send BCH to a dice site and have 94% chance to have their BCH + 4% earnings sent right back. with the Reverse Respend Attack, they play free roughly one time out of ten.

If you make the payment transaction dependent on the funding transaction, this risk disappears, right?
[doublepost=1539888401][/doublepost]

this is out of the question with an 11% success rate on 0-conf, given that exchanges usually permit instant withdrawals. for all a thief has to do whenever his Reverse Respend is successful is pull out as soon as his account is credited, before the next confirmation. money doubled.

the exchange cannot protect itself by delaying the instant deposit transaction by some relatively short time span -- the time differential between the fraudulent and the seemingly honest tx is not key, the attack hinges rather on gaming the fee differentials between standard and non-standard txs.

While true, if an exchange is not happy to take this risk, locking withdrawals until funds are sufficiently confirmed is simple enough. How often is it time critical to be able to deposit, change and withdraw funds? I'm used to that taking days with traditional banking.
[doublepost=1539888948,1539888161][/doublepost]

IMHO, DSV has arguably a small economic downside in the blockspace market, but has huge potential upsides for increasing adoption.

Yeah, I sometimes get the feeling people lose some perspective when it becomes something like a regular transaction takes 10 nanoseconds of CPU time and X transaction takes 15 nanoseconds so OMG, the sky is falling. Similar to the whole manufactured rationale behind the segwit discount and why 2MB blocks are "too much".

I think for many people, there's a real misunderstanding about what you're actually paying for with Bitcoin and the relative costs of each part of the process and what miners and pool operators should be expecting from the deal.

 

[Norway]

Yeah, predicatability is very important. That's why BU, ABC, and others were all trying to stick to a predictable upgrade schedule. Over time, they could become less frequent as the protocol becomes mature and ossifies. Each upgrade is meant to be a manageable change, with releases made well in advance so people have time to upgrade. Then nChain came along and threw everything into chaos and uncertainty.

Developer consensus is probably a bad strategy. No voting system, and people have different perspective combined with Not Invented Here syndrome.

 

[Norway]

On that topic: Is this true?

 

[Christoph Bergmann]

This is lifted straight from CSW's catch-phrase book.

As a starter: Don't reject ideas because a certain person expressed them. This only gives the certain person power over what you are allowed to think, and is usually abused to limit your imagination.

Locking the protocol (after removing the block limit) might have made sense when Bitcoin had 95% of the cryptocurrency market. It has been crippled since and now many other coins are competing. Once this bear market ends we can expect BTC's market share to fall back towards its low of ~33%. The error is assuming that because BCH fixes the original problem which crippled BTC, that the clock can be turned back on the market share struggle. The genie is out of the bottle for competing coins. BCH needs functionality like DSV to put it head and shoulders above its competitors.

Bitcoin Cash was created to allow Bitcoin to scale onchain and to overcome Core's dictatorship towards offchain-scaling. This was the agreement of Bitcoin Cash.There has been no mandate to invent new opcodes or reengineer Bitcoin to handle fantasy-sized blocks.

Now, Bitcoin Cash did not become the leader in p2p cash transactions, as it was meant to become. Bitcoin is still the standard for this, and for what does not fit into its small blocks - there is a large market of cryptocurrencies, which produce a vast oversupply of p2p transaction capacity, while the demand is very limited. As you say: Many coins are competing.

This makes it is a good idea to search new features that make Bitcoin Cash more attractive for users. But there is no agreement for it, no community consenus, no mandate. It is not a given, but you have to search support for it. Some prefer to compete on stability, predictability, hard money purity. Every step towards adding new functionality should be weighted with those other values.

Hardforks always create risks and disruptions. They can be manipulated by sockpuppetery, whales and miners, they risk to split the chain, they can introduce desastrous bugs. Doing a hardfork is fine if it is really needed and / or most people agree. But our story of half-yearly hardforks shows that this is not the case. So, weight the net benefit against the net disadvantage.

 

[imaginary_username]

This doesn't make any sense to me. I assume a wallet/POS product for shops etc will do a doublespend check by polling a number of nodes around the earth for doublespend attempts if a single node have trouble detecting this.

If it's this easy to detect doublespends and alert the merchant whithin a 2-5 seconds window, I would say the problem is solved.

"There exists a costly solution by private providers, so we should stop making openly available and permissionless solutions for everyone else that is free to participate or not participate anyway"

 

[Norway]

@imaginary_username
You don't have to "translate" my sentences into something else. It's better to show mutual respect and argue the points.

I don't think it's very expensive to have doublespend protection as a part of wallets, POS systems etc. Companies doing it today are HandCash, BitPay, ShapeShift etc. And I haven't prevented anyone from making anything. Most people are not using node wallets today. But they are free to do it.

Check out how cool this is:

 

[imaginary_username]

@Norway

>It's better to show mutual respect and argue the points.

I agree, respect has to be mutual. Can't ask for people to respect you without giving out any.

 

[Mengerian]

Personally, I'm going to try to discuss stuff publicly from the start

In the spirit of trying to start discussion early about the next planned upgrade (May 15, 2019), I created a Github repo to gather my thoughts and proposals:

https://github.com/Mengerian/bitcoin-cash-upgrade

The main thing I'm working on there is looking into potential ideas for Merklix-Metadata tree, as an upgrade to the Merkle tree. At this point I'm just working through the ideas, so it's pretty preliminary, and I haven't had the time to really write a good specification for the Merklix part of the tree. I would be interested to hear any feedback or ideas.

I also have a proposed timeline in there. Basically, I'm thinking it would be good to have specifications ready fairly early (I put Jan 1st in there), then code completion a month later, then finalized release Feb 15th, 3 months before the upgrade. This is just my idea, so again I'm curious what others think. Ultimately it's up to the different groups to decide what schedules they want to follow, but it would be nice to have some alignment on the timeline.

Also of note, Shammah Chancellor has also created a proposal for the Upgrade Spec as a Pull Request at bitcoincash.org Github: https://github.com/bitcoincashorg/bitcoincash.org/pull/143

And Jason Cox has created a Pull Request for the nChain "re-enabled opcode" spec: https://github.com/bitcoincashorg/bitcoincash.org/pull/144

 

[Norway]

New client:
https://asynx.io

Is it just a facade, or the real deal?
EDIT: It's a scam

 

[Zarathustra]

On that topic: Is this true?

 

[lunar]

What's the point of these scenarios?

The point is, anyway you look at, we need to get the Tx volume way up, ASAP. Halvings are in 11/2 & 51/2 years. If we're not getting to GB volume by then, the whole project starts to look economically shakey.

It's essential we onboard some major company backends before then. The primary hurdle even after years of debate, is still the f'in blocksize. How can this be? From my perspective it's better to have too much demand and pushing dev teams to optimize accordingly, than wait for Devs to say: 'it's ok you can add a little more now.'

The beauty of having multiple competing clients, is that if one team is slow to react others will take up the slack.
[doublepost=1539963605][/doublepost]Yet another Token and smart contract solution coming soon. Competition is wonderful.

[doublepost=1539963811][/doublepost]

Is it just a facade, or the real deal?

Bitconnect Scammer avoid

 

[cypherdoc]

this forum has some sort of Javascript bug making it unfriendly to "swipe" text on a phone. you won't be hearing from me much until I get back in front of my pc in about another week

 

[cypherdoc]

The primary hurdle even after years of debate, is still the f'in blocksize. How can this be?

thank you