Gold collapsing. Bitcoin UP.

[Peter R]

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?

Yes, they could. Actually, let's follow this line of reasoning further, because the "do nothing" side has been drowned so far in the debate.

The "do nothing" side could argue that double-spend relay and double-spend proofs are misplaced. The information on potential double-spends is already available if a merchant really wants it: like you said, they can set up a global network of listening nodes.

If setting up a global network of listening nodes is too hard for the average merchant, maybe there's a business opportunity. The business model is to reliably collect conflicting 0-conf transactions and provide alerts to merchants who subscribe to the service. The "do nothing" side could argue that trying to provide these alerts at the protocol level instead is doing a job better left to the market.

So I think there are lots of potential solutions to wrap our heads around.

But the point I keep coming back to is an entrepreneur running a vending machine who wants to accept BCH payments TODAY.

Indeed, he could set up a global network of listening nodes, but doing this in a reliable way is a big R&D project in itself. That solution is anything but plug & play. Our entrepreneur is too busy managing his vending machines -- he doesn't want to hire a full-time bitcoin expert just so he can increase sales by a few percent!

Instead of deploying his own global network of listening nodes, can our entrepreneur instead subscribe to a service that will alert him of potential double-spends? I think the answer is "no." Bitpay is the biggest player in the cryptocurrency payments space, but even they don't do double-spend warnings for instant transactions. (I spoke about this with Stephan Pair perhaps 18 months ago, and, unless I misunderstood something, their platform responds only to the first-seen TX. They're not even looking for conflicting TXs AFAIK.)

Right now, I cannot think of an easy and reliable way for that vending machine operator to detect 0-conf double spends. To make BCH more useable as cash, this problem should be addressed somehow.

 

[lunar]

In my view a merchant should use a full node or should pay some third party service to accept payments (e.g. BitPay or others) rather than using a SPV client.

I'm not convinced there's any need to 'fix' 0-conf. I've seen a few good arguments, but I really don't see the need to do anything, but get wallets and merchants to start Implementing proper SVP. They don't need to be a full node (that means mining anyway) all they really need to do imho, is to set up some decent monitoring of the miners. 0-conf like a regular a confirmation is all a probabilistic risk reward analysis anyway. Theres a huge market here for some good devs.

Something like poll the miners of the last 10,000 blocks, a nice little dial on the checkout screen and users wallet that turns red/amber/green as >50>90% of the current hashrate has see the Tx as safe. This whole process would take just a couple of seconds, and deal with >99% of all transactions. The final <1% is fraud, plain and simple.

Fraud can and will be dealt with as BCH scales through two mechanisms, the first is simple insurance companies (the rates would be significantly less than current levels of CC fraud). Secondly companies (probably the same insurance companies and big merchants) would sue the miners for compensation. We must remember a miner that knowingly relays a double spend is complicit in an attempt to defraud and guilty in most jurisdictions around the world. These two forces alone would be enough to push the Nash equilibrium of all miners, so as to never relay double spends and probably even orphan the blocks of the non honest miners attempting shenanigans.

Problems solved.

 

[Christoph Bergmann]

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.

I completely agree with this categorization. In my own articles I called it "the race attack" and the "Peter Todd attack", but we mean the same.

I also agree with you that I'm sceptical of another workshop that only is about the first attack, which is basically eliminated by Double Spend Relaying.

After all, I think you are wasting time and energy for a problem, that is in most cases not a problem at all, and can not be solved completely, no matter what you do.

Every business is ok with a reasonable amount of double spend. In every shop and supermarket and bar people steal things or don't pay for drinks. That is business as usual, and the risk is calculated. As long as such a vulnerability can not be systematically and commercially exploited double spends of instant transactions are not a problem at all. This leaves us with a few application in which it matters: ATMs, exchanges, ShapeShift, Satoshi Dice, physical gold merchants, maybe gift card sellers. The whole rest - supermarkets, bars, online-shops, online-services - can ignore it completely.

With the payment system I built for my book, I confirm every order once I see a transaction. This happens in one or two seconds. Before I ship the book, I just check a blockexplorer if the transaction is finalized. Never had a problem with it, never detected a double spend attempt.

So, you are building for a few use cases. For most of it you can't solve the problem, no matter what you do, because once a miner is actively involved in the double spend, you can only prevent it with two methods: Lightning or CSW's mining cartell. Everything else can harden it, can make it more difficult to perform a double spend, can make it easier to calculate risks. There is not so much to win. You never get exchanges with big volume to accept 0conf; most don't even accept 1conf, but wait for 3 or 6 confs.

I totally disagree with putting too much energy in this. We already have too much fighting in Bitcoin Cash, about every brainfart of everybody, and the issue of double spends doesn't need this kind of attention. It also doesn't need complicated structures like weak blocks or pre-consensus (sorry, I love your work, Peter and Awemany, but in this case I have to oppose), which increase complexity for gaining not so much.

However, I highly welcome Double Spend Relay. It doesn't make RBF attack so much more dangerous (miners need to adjust their software to cancel first seen, and if they do this to profit from fraud, they can easily set up an xt node or use existing XT nodes). On the other side, Double Spend Relay has two extremely valuable pros:
1. It totally eliminates the "synced doublespend". A synced doublespend can be countered with several node or by trusting a couple of block explorers. With low cost infrastructure it is very hard to counter it. Double Spend Relay helps a lot to make it possible for low infrastructure to not mind about this attack.
2. It allows to collect extremely valuable data about the chances of certain transactoinal patterns to be double spent. This makes it very easy to write software that has a high probabilty to detect risky transactions.

The whole fight about this is silly. It makes me really sad to see this.

Did Amaury just ragequit Bitcoin Cash?

In the end, I stand strong with Bitcoin Unlimited, and I'm proud of being a member of this group, which seems to have the onliest reasonable leaders in this space and is able to quietly and constructively cooperate with other implementations like XT. No NIL, no Ego clash, just cooperation. Thank you Andrew, Andrea, Peter, Awemany and everyone else.

 

[lunar]

In other news: all this extra drama around Deadalnix feels orchestrated, or at least there are a significant few who are fanning the flames over what amounts to a miner issue in the grand scheme. Last time I felt this vibe was when r/bitcoin was coming under control of hostile astroturfing.

- find dominant Bitcoin chain
- wedge a division on a significant issue and fan the flames
- force community fork
- force chain fork
- rinse repeat

try not to get dragged down into the astroturf, these are professionals.

 

[awemany]

Is he telling us what he is attempting?

 

[Richy_T]

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).

Completely concur.

 

[Peter R]

I also agree with you that I'm sceptical of another workshop that only is about the first attack, which is basically eliminated by Double Spend Relaying.

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".

The workshop is on all aspects of instant transactions, including RBF double-spends.

The feedback I received when I first started bouncing around this idea was that, since the solution space for RBF double spends is so broad, that the primary focus should be on the low-hanging fruit: addressing the synced double-spend and understanding/mitigating the remaining risk of accepting instant payments.

But the workshop will certainly discuss the RBF double-spend, just as a secondary focus instead of as the primary focus. Here is what BUIP092 said originally:

With your taxonomy (RBF double-spend vs synced double-spend), I've now edited the description to make this clear:

 

[Richy_T]

Relay; Can't work, in cases makes it worse. SPV nodes are not going to ever be notified of double spends using basic relay.

Why is this the case?

Relay; enables this by propagating the tx without time-restriction.

But not having it doesn't guarantee against it either. The double spender could submit it to the miner directly. Potentially, miners could offer it as a separate interface or might be the double-spenders themselves (this last would be pretty much impossible to guard against but is admitedly somewhat unlikely). You can't guarantee what software a miner is running and you can't guarantee what other nodes are going to do. By not relaying, all you are doing is withholding information.

I don't see why doing both shouldn't be the case.

 

[witly]

Is he telling us what he is attempting?

Exactly what I thought. I am sure one of core's strategies against BCH on their table is called "Divide And Conquer".

 

[solex]

### Announcing the next BU Vote: 27th August 2018 ###

For BU Membership information. I will also PM everyone 2 weeks before the start.

 

[AdrianX]

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?

This does not protect from the malisious RBF double spend where the merchant gets say a 90% chance of confirmation if the miner has a 10% hashrate and does not relay the double spend.

 

[Tom Zander]

Why is this the case?

SPV nodes connect to full nodes and then register a bloom filter to indicate which p2pkh addresses they are interested in.
A transaction that pays them, or otherwise includes one of the addresses that the SPV wallet is interested in get sent to the SPV wallet. Nothing other than those that hit the bloom filter are sent to them.

A double spend that intends to defraud the merchant will most likely not pay the merchant, and as such the SPV wallet will not receive it from the full nodes it connects to. The SPV wallet by definition has a very self-centered view of the world and it only sees the part it is involved in.

This means that the relay solution can not work for SPV wallets as they naturally ignores the transaction that intends to defraud them. Since the outputs go to the thief, not the merchant.

 

[Richy_T]

That makes sense. Thanks.

Doesn't this open the SPV wallet up to another form of double spend? A connected node could send the SPV wallet a 0-conf transaction that it never intends to send to the network. I guess if the SPV wallet rebroadcasts the 0-conf transaction, it would guard against this somewhat. But would it? Or is this what fraud proofs are about?

Possibly SPV nodes just need to accept that 0-conf is potentially unreliable.

I'm sure there's some in-depth discussion I can track down on this so don't feel I need an extensive answer here.

 

[cypherdoc]

Yes, they could. Actually, let's follow this line of reasoning further, because the "do nothing" side has been drowned so far in the debate.

The "do nothing" side could argue that double-spend relay and double-spend proofs are misplaced. The information on potential double-spends is already available if a merchant really wants it: like you said, they can set up a global network of listening nodes.

If setting up a global network of listening nodes is too hard for the average merchant, maybe there's a business opportunity. The business model is to reliably collect conflicting 0-conf transactions and provide alerts to merchants who subscribe to the service. The "do nothing" side could argue that trying to provide these alerts at the protocol level instead is doing a job better left to the market.

So I think there are lots of potential solutions to wrap our heads around.

But the point I keep coming back to is an entrepreneur running a vending machine who wants to accept BCH payments TODAY.

Indeed, he could set up a global network of listening nodes, but doing this in a reliable way is a big R&D project in itself. That solution is anything but plug & play. Our entrepreneur is too busy managing his vending machines -- he doesn't want to hire a full-time bitcoin expert just so he can increase sales by a few percent!

Instead of deploying his own global network of listening nodes, can our entrepreneur instead subscribe to a service that will alert him of potential double-spends? I think the answer is "no." Bitpay is the biggest player in the cryptocurrency payments space, but even they don't do double-spend warnings for instant transactions. (I spoke about this with Stephan Pair perhaps 18 months ago, and, unless I misunderstood something, their platform responds only to the first-seen TX. They're not even looking for conflicting TXs AFAIK.)

Right now, I cannot think of an easy and reliable way for that vending machine operator to detect 0-conf double spends. To make BCH more useable as cash, this problem should be addressed somehow.

MoneyButton doesn't employ a global network of listening nodes; he just employs one connected node on the other side of the planet. since the entrepreneur is going to likely setup one full node this only requires he setup a second node. or, he can just use Blockcypher's Confidence Factor service:

https://www.blockcypher.com/dev/bitcoin/#confidence-factor
[doublepost=1533787486,1533786856][/doublepost]and not every merchant entrepreneur needs setup a second node, just enough of them to act as a deterrent. we're talking about coffee spends here for the most part. it's like those fake ADT alarm system signs that get put up around your neighborhood. some houses actually have the system, many others don't. or those fake video security cameras on commercial buildings. enough places have them to stop most burglars. merchants could even display signs, "Warning: Global listening nodes"
[doublepost=1533787721][/doublepost]i just don't hear any DS complaints; on either the BTC or BCH sides from merchants or users. and for years. and then there was the epic /u/Sharklazerrrr challenge. sure, you had to risk $2000 to try and steal $1000, lol. and some schmuck lost showing just how hard it is to pull off

 

[Mengerian]

@Mengerian, is an ABC testnet running with OP_CHECKDATASIGVERIFY enabled? If I compile current ABC from source, is the opcode enabled for regtesting, or do I have to do something special?

@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

@awemany the activation code was just committed this morning: https://reviews.bitcoinabc.org/D1625

I believe the plan is to get a testnet up and running sometime after next week's planned release of 0.18.0

Running the node with "-magneticanomalyactivationtime=<timestamp>" should activate it, when the median timestamp of the prior 11 blocks is greater than <timestamp>.

It should be possible to get it working with -regtest, I'd be interested to hear if you're successful with that!

 

[Peter R]

@cypherdoc

Those are all fair points. But even if I were to concede to all of them, what's wrong with double-spend relay or double-spend proofs? There are clear benefits, but what are the downsides?

 

[Daniel Lipshitz]

If setting up a global network of listening nodes is too hard for the average merchant, maybe there's a business opportunity. The business model is to reliably collect conflicting 0-conf transactions and provide alerts to merchants who subscribe to the service.

This is part of what we do at GAP600 - www.gap600.com our BCH solution will be available Sept/Oct. We financially guarantee BCH & BTC zero confirmed transactions for service providers, we score all trxs as they are published and our clients query our API via trx hash. Our analysis is based on failed transactions and experienced fraud. A major reason double spend risk causing people not to accept zero conf is not necessarily the chances of it happening but very much the perceived risk of loosing money doesnt matter how small.

I am not sure that just relaying the double spend transaction as a normal transaction will have the desired effect - as yes technically non-mining nodes will be able to know if there is a double spend attempt but one of the results will be that there will be more occurrences of double spend on the network it will be easy to perform, so the perceived risk will increase and there will be an increase of fraud occurrences and one wont be able to know if there is actual loss or not behind them.

I would think a relay mechanism which flags it as a double spend, or a separate pool of these double spend attempts - something which ensures it is clear this transaction should not be included in a block. But an approach like this opens up to abuse and spam attack - so needs to be full thought through.

 

[awemany]

@Mengerian: Thanks, yes I'll try! So much to do, though. But it gives me some confidence that OP_DATASIGVERIFY is indeed a good idea if it can be used in unforeseen but productive ways Thanks @theZerg for inventing it and thank you guys for refining it to its present state. Now I just need to test whether what I thought is actually feasible.

 

[cypherdoc]

we're doing it all over again :
https://i.redd.it/gzucrcenk2f11.png

 

[cypherdoc]

@cypherdoc

Those are all fair points. But even if I were to concede to all of them, what's wrong with double-spend relay or double-spend proofs? There are clear benefits, but what are the downsides?

@cypherdoc

Those are all fair points. But even if I were to concede to all of them, what's wrong with double-spend relay or double-spend proofs? There are clear benefits, but what are the downsides?

i don't know, maybe what @Daniel Lipshitz said? btw, when i published my newsletter, i'd always accept 0 conf, with never a problem too.

also, i've noticed we never really talk about price anymore. maybe b/c it's a fools errand to begin with and healthy to focus instead on the fundamentals. i agree with this. but at some point, you have to ask yourself why the BCH price keeps dropping along with the ratio. maybe it's b/c BCH devs are going down the same path of constant tinkering with the base money protocol? encouraged by the q6mo hard forks? it seems we've convinced ourselves that BCH & BTC are bullet proof and destined for unquestionable success. i actually DO think that but still pause every once in a while to ponder ultimate failure. what happened to the message that changes should only happen under dire circumstances, blocksize being one of the only things i can identify? no one is complaining about being double spent.