Gold collapsing. Bitcoin UP.

[awemany]

@sickpig: Didn't find it in D1621, I assume that's another commit?

 

[sickpig]

@awemany "Magnetic Anomaly" (this is how ABC call Nov 18 upgrade) activation code has been added via the PR that implemented canonical transaction ordering, see: https://reviews.bitcoinabc.org/D1487

 

[cypherdoc]

I'm on record from day 1 stating q6mo hard forks are a bad idea in BCH. I felt it would incite all sorts of in fighting between eager beaver devs trying to get their favored code modifications inserted before each deadline. I believe we are seeing exactly that.

I'm the one who coined the phrase "devs gotta dev."

Get the fuck rid of it for our own survival.

edit: just to be clear. i think BCH survives either way but getting rid of the q6mo hard forks would make for a less contentious and competitive environment that we've seen blossom in <1y

 

[Richy_T]

The really big issue is that in the current system we can say that after 5 to 10 seconds nobody will accept a second transaction anymore.

Anyone attempting a malicious double spend is going to be working well under that number anyway.

I see a few other issues in what you're saying also. For example, how else would you notify another node of a double spend other than sending the transaction itself? Double spending requires two otherwise valid nascent transactions and the truth of validity is the transaction itself.

To be fair, I do think that some of the justifications for relaying double spends are weak but I also think that some of the reasons for *not* relaying double spends are also weak. The main justification for relaying in my mind is that 0-conf is inherently unreliable anyway (This is fundamental to Bitcoin's design) and that, for a merchant, as is so often the case, more relevant information is better. Double spend attempts happen. Is it better to keep people in the dark or allow them to see it? At the end of the day, the job of the network is to relay *valid* transactions and both nascent transactions in a double spend are valid until one of them mined into a block.

I also think that there are some things that could be done to ameliorate some of the criticisms of double spend relaying. Want to make "first seen" more of a thing? Number the relayed transactions in order of being received and pass this along when you relay. Miners could still mine the later transactions, of course but in a double spend attempt, the spender will be using "methods" to get their double spend transaction to the miner(s) first. So not relaying it is not especially helpful.

An overarching concern is that this is leaning toward tribalism again. People are against relaying double spends or against not relaying double spends and will glibly dismiss the concerns of those whose opinions differ. What we need is a good pros & cons comparison and looking at whether it makes more sense to work to address the concerns of column A or column B.

 

[cypherdoc]

hmmm, interesting post:

https://www.reddit.com/r/Bitcoin/comments/95bi14/hillarious_creator_of_bcash_has_been_banned_from/

 

[Bagatell]

@cypherdoc someone asked if he'd been hacked. I hope he wasn't hacked the same way as AA.

 

[cypherdoc]

@deadalnix have you been hacked on reddit? if not, why would you seek sympathy from r/bitcoin while also crying Bcash?

 

[satoshis_sockpuppet]

@cypherdoc
I'm pretty sure he hasn't been hacked, I bet on meltdown of an egomaniac.

It was a matter of time. He has shown the same mentality as Greg Maxwell.

 

[awemany]

@cypherdoc: I am actually quite happy about BCH's pace, at least regarding validation rule changes. Slow (some might say glacially so), but non-zero.

Now, of course, there's idea / plans / changes that simply need time to do even though most folks are in agreement that they should be done. Those things can obviously not happen fast enough for the impatient. But then good stuff simply takes time. Example: UTXO commitments.

But in terms of protocol change speed, I personally think we're at the sweet spot now.

Are we seeing instances of 'devs gotta dev'? Sure enough. Am I guilty as well? Most likely. But overall I think things are definitely moving into the right direction.

 

[Norway]

I try to understand doublespend and organize this in my head. This is how I currently see it:

There are basically two different types of double spends people are talking about.

1. The synced doublespend. The spender broadcast two transactions at the same time, one probably on the other side of the world. All nodes, miners included, disagree which was broadcasted first.

2. The RBF doublespend. The spender broadcast a second transaction with a higher tx fee after the first payment. After almost every node has seen the first tx, but before a new block is mined. A miner might choose to prioritize this tx and include it in his block because of the higher fee.

Is this the right perspective?

We need to have a terminology when we talk about these problems. We need the words.

If I have understood this correctly, I suggest people use the terms "synced doublespend" and "RBF doublespend" when we discuss.

 

[Peter R]

@Norway

You're exactly right. There are two distinct classes of 0-conf double spends: like you said, there is (1) the synced double spend, and (2) the RBF double spend.

In Satoshi's famous "vending machine" thread, he talked about waiting a few seconds to check for conflicting transaction before releasing the merchandise. This was to address the synced double spend. The trouble is that right now, if a merchant is operating that vending machine, he doesn't have a reliable way to learn about these conflicting transactions in the first place! (E.g., they may only be relayed on the half of the network he's not directly connected...and the problem is even worse if he's running a SPV node).

I don't think anyone who understands the distinction between the two classes of 0-conf double-spends is opposed to getting instant transactions working more like Satoshi envisioned in that vending machine thread. That is, I don't believe anyone is opposed to making synced double-spends more difficult. There is just debate about how exactly the notifications of the conflicting transactions should be done. For example, we want the vending machine operator to know that a double-spend attempt is under way, but in doing that, we don't want to make the double-spend more likely to succeed, or to make it easier for dishonest miners to perform the RBF-class of double spend.

The workshop we're planning for October will be focussed primarily on the synced double-spend.

If none of the miners offer RBF services (and if there's no way for a would-be double-spender to game heterogeneity in miner mempool policy), then instant BCH transactions would be quite secure (more secure than credit cards) within a few seconds once the synced double spend is dealt with.

Improving the RBF double-spend is a longer-term project. There are potential solutions like preconsensus, subchains/weakblocks, and @awemany's new idea. Or perhaps RBF double-spends are so rare that we don't need to do anything.

 

[Richy_T]

If I have understood this correctly, I suggest people use the terms "synced doublespend" and "RBF doublespend" when we discuss.

Good point. I'd also like to see a move away from calling a 0-conf transaction a transaction without qualifying it in some way. I think this is leading to some unfortunate wrong-headed thinking.

RBF doublespends are actually less of a threat. Merchants should simply not accept 0-conf payments that can be RBFed (Assuming we're talking about RBF flagged transactions and not just ones that are hoping the miner will operate an RBF policy on regular transactions).

If none of the miners offer RBF services

This is not really something you can ever guarantee though. If you try, I think you're opening a can of worms.

 

[cypherdoc]

The trouble is that right now, if a merchant is operating that vending machine, he doesn't have a reliable way to learn about these conflicting transactions in the first place!

If a merchant is worried about this and big enough to run a full node, why not run a second well connected full node on the other side of the planet like the Moneybutton?

 

[cypherdoc]

@cypherdoc: I am actually quite happy about BCH's pace, at least regarding validation rule changes. Slow (some might say glacially so), but non-zero.

Now, of course, there's idea / plans / changes that simply need time to do even though most folks are in agreement that they should be done. Those things can obviously not happen fast enough for the impatient. But then good stuff simply takes time. Example: UTXO commitments.

But in terms of protocol change speed, I personally think we're at the sweet spot now.

Are we seeing instances of 'devs gotta dev'? Sure enough. Am I guilty as well? Most likely. But overall I think things are definitely moving into the right direction.

the current pace is fine but the q6mo hard fork frequency sets up unrealistic expectations for bigger changes, like GROUP, from not only devs but businesses and investors that have gotten competitively out of hand. hence the intense infighting and small world-like dislike btwn all BCH development teams. it's ugly but predictable as each is struggling to gain relevance (BU, XT, and Flowee mostly) while ABC tries to keep control. we already know the community is willing to hard fork when needed but do we really need to setup a schedule?

 

[Norway]

The workshop we're planning for October will be focussed primarily on the synced double-spend.

I will vote NO to the funding of this potentially very important meeting in the most beautiful part of Italy if the RBF issue is not "in focus".

I don't want to waste BU money on circle jerks.

I don't believe in a security model based on miners not allowed/ hidden/blocked by double spending filters "hiding" transactions from miners. But I think @deadalnix, @Tom Zander and other people should be welcome to say their concerns and present it.

 

[Norway]

Don't get me wrong. I'm 100% pro this initative. But the conference/meetup should be aware of the short term incentive for a miner to include the highest fee-paying tx, and the players who think this is important.


WHAT? You ask me how it should be?

My wet dream: Miners should orphan blocks including 3 seconds or more old doublespends.

 

[awemany]

This is not really something you can ever guarantee though. If you try, I think you're opening a can of worms.

It can be measured however. With the qualification that the measurement might be of a state that is highly dependent upon BCH's current public perception and usage patterns.

This is why I think the right approach is multiple levels of defense: Implement the easy stuff first and if that means assuming the majority of the miners to not mine RBF too much, then so be it.
But also work on other solutions. Acknowledge the potential problem of short term incentives while also not throwing the baby out with the bathwater (e.g. implementing full RBF).

the current pace is fine but the q6mo hard fork frequency sets up unrealistic expectations for bigger changes, like GROUP, from not only devs but businesses and investors that have gotten competitively out of hand. hence the intense infighting and small world-like dislike btwn all BCH development teams. it's ugly but predictable as each is struggling to gain relevance (BU, XT, and Flowee mostly) while ABC tries to keep control. we already know the community is willing to hard fork when needed but do we really need to setup a schedule?

Fair points. I think the 6 month schedule is indeed debatable. The process is messy but so far, I think the results so far are good.

And, to be honest, some infighting is healthy IMO. It is a sign of balance of power and multiple factions competing. You are right of course, that this shouldn't get out of hand to the point of being destructive (and in part it might be) and also that nothing drastic should be done just to temporarily please some subset of investors.

As you know, I am hesitant on e.g. token groups as well, but I was the same, to a lesser extend, on theZerg's OP_DATASIGVERIFY as well. On the latter, my opinion shifted quite a bit to the supporting side, so maybe that's why I feel the process is working

Basically, it seems to me that stuff that has too many question marks attached still (like token groups) won't easily make it but the stuff that survives most criticism and refinements will.

I will vote NO to the funding of this potentially very important meeting in the most beautiful part of Italy if the RBF issue is not "in focus".

I don't want to waste BU money on circle jerks.

I don't believe in a security model based on miners not allowed/ hidden/blocked by double spending filters "hiding" transactions from miners. But I think @deadalnix, @Tom Zander and other people should be welcome to say their concerns and present it.

Disclaimer: I tentatively plan on going to the workshop if it takes place, so I might be biased

What do you think would make it so that workshop would put RBF into focus?

I believe that e.g. both weakblocks as well as my above "ZCI" proposal (which has to be proven feasible yet!) would actually address the RBF issue to varying degrees.

But, as I said above, you go at the low hanging fruits first (even if they don't address the RBF incentive issue) and it seems to me that most people agree merchants knowing about double-spend attempts while still not mining 'the wrong' transactions is the general direction to go to.

How that's going to happen in detail in all cases is yet to be determined, hence the idea of this workshop.

 

[Tom Zander]

There are basically two different types of double spends people are talking about.

I like this.

Many are asking to compare the two proposals I've seen. XT has introduced one in 2015 and I've been thinking and designing one (the proofs) for flextrans and per request here on the forum I re-designed it for BCH in general.
I am not aware of any other far-progressed idea to fix the The synced doublespend.


A pro-con series of scenarios for relay and proof.

For merchants with SPV wallets.
Relay; Can't work, in cases makes it worse. SPV nodes are not going to ever be notified of double spends using basic relay.
Proof; no harm to SPV, wallet can add support for the new message and then they get DS warnings paired with their incoming payments.

Full nodes (big merchants, exchanges and geeks).
Important to notice that in most cases those people already have protection and already have notifications capabilities.
Relay; Helps a little.
Proof; Helps a little. Potentially helps more as the proof message can be prioritized for speed.

Miners;
Relay; slightly biased for the first transaction.
Proof; mostly agnostic.

RBF-like double spend;
Relay; enables this by propagating the tx without time-restriction.
Proof; depends on the first-seen and the lack of RBF to fight this (i.e. no change). Doesn't enable it because the proof itself isn't minable.

 

[79b79aa8]

BTC speculators (class of '17) want to be rich, asap. these are no longer people who took a risk with something unproven and reaped the rewards, but rather people who know for a fact riches have been made, and don't want to miss out again.

anxious to speed things up in a market that is not half-way to capitulation, such people look for ways to contribute to the advancement of the space. alas, room for innovation is limited in BTC itself. not only that, there is nothing being brought to market on its second layer for a normal person to as much as try out. basic incentives even militate against using BTC for its fundamental application, payments/commerce.

left with little to do pro BTC (and possibly in the red), a holder might at least try something against its competitors . . . maybe their narrative can be muddled? better yet, maybe they can be induced to fork! hoist BCH with its own petard! the strength of multiple implementations becomes a weakness if one of them goes rogue. fuel little fires, amplify the clash of personalities, promote personality cults . . . these are the sorts of contributions within the reach of such activists . . .

. . . et deadalnix a voulu les troller.

 

[cypherdoc]