Gold collapsing. Bitcoin UP.

[79b79aa8]

here’s a true story to pass the time, since everyone seems to be in summer mode. middle-aged accountant gets job as CFO of an US ethereum startup. founders are young, he’s the adult and the one in charge of running a business. except it’s not clear what the startup does. it doesn’t matter, ICO funds have been raised and the firm is looking for activity. some guys in italy get in touch. CFO flies over for a business meeting. what they want boils down to buying ETH for cash. CFO doesn’t need time in jail, flees the meeting, flies back. outfit countinues to burn down the funds.

also: wormhole tokens, which cost 1/100 BCH to mint (i.e. $7 atm, except it takes 1000 blocks to receive them), are trading for $50.

too much nonsense.

 

[Bagatell]

@79b79aa8

 

[Norway]

 

[sickpig]

@Tom Zander I just wanted to ask a thing about SPV and double spend attack.

What's in your opinion the amount of merchants that will use an SPV client connected to a random non trusted full node to accept a payment?

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.

On the other hand I see a buyer using a light client to buy something froml a merchant, same buyer would use a trusted full nodes to transfer funds to his light wallet.

Do you think this scenario is plausible?

In that scenario isn't double spend relaying used as a mechanism to detect fraud something better than the status quo?

What's your take on this?

 

[awemany]

@Mengerian:

I am right now due to some discussions on the BU slack wondering about OP_DATASIG(VERIFY), 0-conf and 'poison transactions'.

Assume the following scenario: I want to spend fast (0-conf) at a merchant while the merchant feels safer about receiving the money.

I create a transaction template for a bunch of inputs for which the only thing missing is two distinct signatures of ANY data (but with the key for the given input) for any input to make it valid. The transaction spends all inputs as fees.

I give this transaction template to the merchant.

I then sign a normal transaction and send it to the network.

In the case that I am a scammer and assuming there's a significant fraction of RBF-miners, I could send a 'replace by fee' transaction to my special colluding miner to scam the merchant.

But if there's a feature available and easy to use that could allow merchants to request 'poison transaction templates' from customers, this would create an incentive for miners to publish double spends, even if they would still mine the one with higher fees.

And if I then see the double spend, as a merchant, I could fill and send the poison transaction into the network, which would benefit any miner who mines it but keep the scammer from getting the money. As it spends everything as fees, it will be mined by any miner purely interested in the fees and not any of the "higher goals of network health".

Which I guess would likely disincentive double-spending.

Is something like this possible with the new opcode?

(shout out to @imaginary_username and @theZerg for some of the ideas)

Oh and interpret 'transaction template' above loosely: If it means the customer sends to an adequately encumbered P2SH address that would allow the merchant to spend all as fees using any two distinct signatures, that might be a viable solution as well.

 

[Mengerian]

@awemany I think what you describe should be possible, if I understand correctly.

Basically the scriptSig would supply two signatures and data. The scriptPubKey would check that the two signatures are not equal, and that they both are valid signatures of the respective data for a given pubKey.

I guess a limitation is that you couldn't re-use the address, since any other signature corresponding to the same public key could also be used.

 

[awemany]

@Mengerian: Thanks! I am glad to hear. Yes it would require some care on the customer's wallet side to be sure to not reuse the address for anything else. But at least it would open an interesting opportunity to deal with 0-conf security in another way.

EDIT: So, @Mengerian, as a refinement of the above, could I essentially create a set of two transactions, like this, as a customer:

txn1: Customer Input 1 -> Merchant output
                       -> Customer Change output

txn2: Customer Input 2 -> "I will not double-spend Input1" output back into customer's wallet

and make the "I will not double-spend Input 1" spendable predicate something like:

(<datahash1> != <datahash2> && checksig(<datahash1>, input1_pubkeyhash) && checksig(<data2hash>, input1_pubkeyhash)) || checksig(...)

Meaning that the customer creates an anti-double-spend insurance output that anyone could spend if there ever appear two distinct signatures for input1?

This way, the customer could put up a, compared to the item transacted, relatively large sum of money that depends on him not double-spending txn1.

Compared to let's say LN, he also won't ever "lock" that money in any way as he can immediately go on and continue to spend the output of txn2. Just in the case that he attempts to double-spend txn1 would he (likely) lose the output of txn2. He could attempt to double-spend just txn2, but that doesn't hurt the merchant in any way.

Does this scheme make sense? I can imagine that wallets could provide this as some kind of "anti-double-spend insured transaction" or so?

 

[Tom Zander]

@Tom Zander I just wanted to ask a thing about SPV and double spend attack.

What's in your opinion the amount of merchants that will use an SPV client connected to a random non trusted full node to accept a payment?

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.

Hi sickpig, thanks for pinging me. I only noticed just now...

Merchants using SPV is the majority of cases. I've been paying in real life with Bitcoin for years and most of them just use a wallet on a phone.

The fact of the matter is that there has not been a free point-of-sale system for Bitcoin (/Cash) out there for years. We now have systems like minipos which will become more popular over time but those are still not full nodes. People just ended up using the obvious solution. A phone wallet.

I understand and agree that a merchant should use a full node or pay someone to. But if you have a monthly cost to merchants as a requirement then suddenly they are no longer interested.

I have to add that there are some rather large service companies which added Bitcoin/Cash to their lineup of payment methods, which likely means they run a full node. Fast food websites in Germany/the netherland for instance. I do hope we agree that this is nice, but should not be required for merchants to use.

My personal goal for bitcoin cash is that we can out-compete the insane amount of service companies everywhere. Make things easy enough that they can run it themselves and due to the lower cost to merchants we all benefit.
[doublepost=1533554185][/doublepost]

@Mengerian:
I give this transaction template to the merchant.

Would the thief be able to double-spend this template at the same time he double-spend the merchant?

 

[awemany]

@Tom Zander :

Would the thief be able to double-spend this template at the same time he double-spend the merchant?

Yes, of course, but look at the incentives!

The 'anyone-can-spend-if-I-double-spend'-output can of course be double-spend by the thief.

But what is a RBF-ing miner going to mine? The one giving him the most money. Which is the transaction that would double-spend all the money to him as fees. So the thief is out of luck on that front.

The miner could even construct that transaction himself.

Thinking about it, I'd probably even go and explicitly encourage RBF in just this special case by 'the good miners'. Allow just the special case of a transaction that spends all the fees to a miners to be mined, replacing whatever other transaction exists with the same inputs.

Then the above extra transaction would basically amount to an enforceable promise by the customer that says "I will not double spend these inputs, or else I will do 'community service' (by paying the miners as they can fulfill the anyone-can-spend-if-this-other-output-is-double-spent criteration)".

Let me coin "ZCI - Zero Conf Insurance" for this scheme.

With DATASIGVERIFY and assuming it is doable with the planned implementation, wallets could provide a button that says 'Use X mBCH to insure my outputs against double-spends by myself'. And on the merchant side this could be displayed as a big green box that says 'this output is zero-conf-insured against double-spending up to xBCH'.

Over time, I can imagine that merchants either use the good old trust relationship to the customer (he's always buying the coffee here and I know him personally) or require ZCI with an insurance payout to the miners above the value of the item. Payment request protocols could be updated to allow the merchant signal his ZCI requirements.

I think just implementing this and making it available in a widespread way will likely discourage even attempts of miners to provide special RBF-interfaces for scammers.

 

[sickpig]

@Tom Zander

Merchants using SPV is the majority of cases [...]

I would have thought the opposite were true. I have no reason to say this is not true I was just basing my estimate on the way I'd have set up a mechanism to accept payments via BCH.

So at least we have clarified that in case a merchant is using a full node (directly or not) to accept a 0-conf payment, double spend relaying won't make the status quo worse, on the contrary. Am I right a thinking that?

But if you have a monthly cost to merchants as a requirement then suddenly they are no longer interested

Dunno for the rest of the EU/World, but in Italy since the end of 2017 in Italy merchants are forced in using some kind of POS machine to accept payments via debit/credit cards.

I just skimmed through the price list of the more used providers fir this kind of HW. Well what I found out amazed me. There's a fixed cost of 25 Euro/month (at minimum) plus a per purchase fee that range from 1% to 2.9% of the amount transacted.

At this cost adding a way to accept BCH that does not bring any fixed cost and that have a fee around 1% or less would be a good thing to have for any merchants out there.

I do hope we agree that this [using 0-conf w/o relying to 3rd parties and w/o running a full node] is nice, but should not be required for merchants to use.

I agree.

 

[Tom Zander]

@Tom Zander :But what is a RBF-ing miner going to mine?

The double spend of the everyone-can-spend... Because you gave the everyone-can-spend to the merchant, not the miner. Your double spend of that is just a normal transaction.

 

[Tom Zander]

@Tom Zander
So at least we have clarified that in case a merchant is using a full node (directly or not) to accept a 0-conf payment, double spend relaying won't make the status quo worse, on the contrary. Am I right a thinking that?

A full node already gets notified about double-spends, assuming they check (Flowee does). Its not perfect (hence the proof) but its pretty good and doesn't really require much of an improvement.

But back to your question.

There are lots of reasons why a transaction is not accepted in the mempool of a full node. Many to do with local configuration. For instance a node uses a too high min-relay-fee (he copied the config from some core howto for instance). BU rejects transactions at a configurable maximum size is another.
But zero-fee transactions are also a great example which are rate limited by default and as such there is a simple way for an attacker to make the chance of a full node not seeing his transaction higher.

If a remote full node doesn't have one of the two transactions of a double spend, then relaying the other to them is a net negative. Because you are not giving a double spend notification, you are sending a transaction and assuming the other side will conclude it is a double spend. That strategy only works if everyone has exactly the same mempool and exactly the same rules for accepting transactions. And this is simply not true.

Another example where this is not true is in the case of a full mempool (think 1st aug or 1st sept) and low-fee transactions are pushed out of the mempool.

In all these cases the exepected outcome is that a full node concludes it is a double spend, but the actual outcome is that people using that node just got confirmation of a transaction. Which is exactly the opposite of what you wanted.


Now, the really big issue with relaying known double spends is not just that you might hit a node that doesn't have the other transaction. 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. But BU relaying one anyway removes that protection! It essentially means that a thief can wait as long as it takes till the next block comes and double-spend in that time.

So where before a thief had to do exact timing and make sure he hit the right nodes, all of that is gone if you start relaying the double spend transaction.

This is because this relaying destroys the first-seen adage. And the first seen adage is what gave us the timeout because even if a section of the nodes (doesn't have to be 100%) rejects a transaction, it won't propagate under the 'first seen' adage.

BU and thezerg noticed that it would be wonderful if in a point-of-sale software the wallet sends the transaction to the merchant first so the merchant broadcasts it. This is useful to make the timing requirements practically impossible to cheat with. As the thief doesn't know exactly when the transaction will be broadcast.

This advantage is taken away if you relay double spends, suddenly there is no time constraint anymore (other than the tx being mined)...

At this cost adding a way to accept BCH that does not bring any fixed cost and that have a fee around 1% or less would be a good thing to have for any merchants out there.

Fully agreed!

 

[cypherdoc]

[doublepost=1533569955][/doublepost]Great insight from, of all ppl, Lloyd Blankfein:

https://www.bloomberg.com/news/videos/2018-06-19/goldman-s-blankfein-says-he-s-not-worried-about-cryptocurrencies-in-systemic-way-video

 

[awemany]

The double spend of the everyone-can-spend... Because you gave the everyone-can-spend to the merchant, not the miner. Your double spend of that is just a normal transaction.

Well, the idea is of course that the everyone-can-spend-with-two-distinct-sigs is propagated through the whole network as well!

Which means that when the scammer scams and double-spends, any miner can spend the insurance output .. which is the full amount whereas any double spend of the insurance transaction that could be of interest to the scammer will necessarily be less (else he won't get any money out of it!).

I think the incentives work out quite well, actually. Anyone, please shoot holes in this

 

[cypherdoc]

here's a great article coming at LN failure from the opposite direction that most of us have criticized ala hubs. makes sense to me, based on abrkn's experience:

"Yes. If a node representing 50% of the entire network, routing most of all the payments in it can only make less than 1 dollar in 1 week, then who would be incentivized to lock up so much capital to be a LN hub? "

https://www.yours.org/content/bitcoin-s-economic-gambit----or-why-btc-is-dead-13c57a0eff5d

 

[Peter R]

BUIP 092: Workshop on Instant Transactions for Bitcoin.

https://bitco.in/forum/threads/buip092-workshop-on-instant-transactions-for-bitcoin.20766/

 

[awemany]

I have found a paper now that is in some areas superficially similar to my approach from above, in the sense that they also propose a punishment for having two transactions. IIUC, they are having to prepare special outputs for this, however! - and rely on details of ECDSA signing to make their thing work:

https://eprint.iacr.org/2017/394.pdf

With OP_CHECKDATASIG(VERIFY), I believe a simpler and much more streamlined approach is going to be possible, also one which does not need any preparation on the part of the merchant or the customer, the only non-technical requirement for the customer is him or her having an amount that is more than his payment to the merchant available to put up as the mentioned insurance.

Their analysis of the incentive situation would also hold for my above approach, however, as far as I can see.

Now, I might hit insurmountable roadblocks in the detail with my approach, but I am intrigued enough by the idea so that I really want to try it out!

@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?

 

[AdrianX]

I think the incentives work out quite well, actually. Anyone, please shoot holes in this

As a customer I thinking through all the things that could go wrong I feel uncomfortable knowing I could lose my money if someone thought I'd tried to double spend.

I like the incentive to not double spend, but I feel I'm taking on extra risk as a customer - my payment may get lost. I'd only like to see this enabled on a POS if the merchant were actually having to deal with fraud.

 

[awemany]

@AdrianX:

As a customer I thinking through all the things that could go wrong I feel uncomfortable knowing I could lose my money if someone thought I'd tried to double spend.

Well, someone thinking you are going to double-spend doesn't make you lose your money. Only you actually double-spending would. (Modulo implementation bugs concerning address reuse, but that seems very manageable)

I like the incentive to not double spend, but I feel I'm taking on extra risk as a customer - my payment may get lost.

Yes, you take on extra risk. But the risk is basically identical to zero if your wallet implements the protection right. You pay a higher fee for the extra output. But this might enable you to actually do business with a merchant who's suspicious about his customers (whether justified or not).

It is for bridging the trust gap that would exist in a world where 0-conf double-spend exploits are common. I also hope other techniques will reduce this so it might not be necessary, but then I think having the extra safe layer on top doesn't hurt either!

And this is for the walk-in-walk-out situation (and maybe instantaneous stuff on the internet), for which the value transacted is typically at most double-digit $-equivalent. The insurance you'd put up is a similar amount. Would surely suck if you lose it, but won't screw with the rest of your life.

And, as I said, this not happening is just dependent on a correct implementation that doesn't reuse privkeys.

I'd only like to see this enabled on a POS if the merchant were actually having to deal with fraud.

Yes, I can imagine just having the option around and easily accessible is enough of a discouragement for scammers. Maybe double-spends will flare up once in a while in some area and then the ZCI protection gets enabled by merchants for a while.

This is up to the implementation of the POS and the merchant, whether the merchant requests double-spend protection from customers or not and whether he can enable/disable it, or not.

Of course, I'd like to have choice there, as well.

 

[sickpig]

@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?

Usually there's a flag/conf param to set a custom time to trig HF features.