Bitcoin Forum

Would it be possible for nodes to instantly validate a tx, without the help of the network, after all every node has to full tx history, and is actively monitoring the network. they wouldn't actually add a confirmation because they aren't mining, but they can instantly check to see if the tx is valid / not a double spend. and be 100% or 99.99% certain that the tx will get confirmed?

this could  add a level of comfort, or even completely eliminate possibly of double spend for accepting 0 confirmation BTC payments.

just a thought, what do you think? is this possible?

---

If a TX (with a miners fee), is broadcast, and no double spends accourcs 60 seconds after this TX has been broadcast, we can assume this TX will be confirmed, EVEN if a double spend is initiated after the 60 seconds. because when a miner is validating TXs he will see the first tx ( the one that occurred 60 seconds before the double spend attack) as the valid one.


so....

if you get a payment, make sure it has a miners fee, and look for double spends for 60 seconds, and you see no double spends, you can be sure it will get confirmed, even if a double spend is initiated later.


thats the idea. i understand this is an ugly solution, but if it works.... "Safely accept 0 conf. BTC payments in 60 seconds!"  ;D

While the tx is broadcast as long as the tx is not confirmed the money is not owned by the receiver. The original owner is still in control of the money and can broadcast different txs with the same input. There is no guarantee the tx that sends the money to you will be confirmed before the other tx. Thus a double spend is possible for any tx that hasn't been confirmed.

0 conf tx is not safe because until the tx is confirmed no money has actually moved. Double spend attempts can be made at any point in time from the original tx broadcast until it is confirmed. Until the tx is confirmed the validity of the tx can change so the node can't validate a 0 conf tx.

Full nodes have the entire blockchain, so they can verify if a tx is valid and if it doesn't use any spent outputs (that is, it's not a double spend).

But you can't assume that a node has perfect connection to the network, so a double spend is easily possible if you perform the two spends on different parts of the network that are poorly connected. It may take many seconds or even longer for these nodes to synchronize. If you accept 0-conf transactions, you're vulnerable to double spends this way. For small amounts, this isn't a big deal, as the effort required to attemp to double spend isn't worth it typically.

there's no way to predict that even if the owner tried to double spend, the original tx would get confirmed?

say you waited 1 min, and saw no double spends, if the owner tried to double spend after that minute, which of the 2 tx will be deemed the valid one?

the first one? how does the network decide which tx is the valid one?

assume the "confirmed-by-owner" program, is done with a super well connected node and waits 60 seconds looking for double spends, b4 saying " it will most likely be confirmed "

So far, there's still an "official" warning against zero-confirmation.
https://bitcointalk.org/index.php?topic=135985 (https://bitcointalk.org/index.php?topic=135985)

8.0. was the last time I've seen an improvement regarding this, but I might be missing newer changes.
https://bitcointalk.org/index.php?topic=145184 (https://bitcointalk.org/index.php?topic=145184)

All full nodes already do validate every transaction and will not display one that won't validate or which depends on parents which won't validate. But you can't be sure no matter how much you observe that an alternative double spend won't get mined instead of it.

The problem here is that both tx would be valid. Both tx have valid inputs they are just sent to different receiving addresses. Whichever gets confirmed first becomes the "true" valid tx. As the inputs would now be spent the other tx becomes invalid and would never get confirmed. The order in which tx gets mined into a block depends on many variables. The time it was broadcast, how many other txs are waiting to be mined, the priority of the tx, etc..

One trick to double spend a 0 conf tx is to send the first tx with no or an extremely small fee so it stays at the back of the queue for tx waiting to be mined. This increases the probability that it won't get included in a block for a long time. Although this tx is broadcast first it will likely take a very long time to get included in a block hence a second tx can be made minutes after the first and propagate throughout the network. The second tx can be created paying a very high fee to jump in front of the queue of txs waiting to be mined and increasing the probability that it will be mined before the first tx.

Currently there is no way to have a valid 0 conf tx. You simply have to trust the sender won't double spend.

There are but they're mildly complicated and have other restrictions.

Can you enlighten us as to how this is possible?

this is the key, if you wait long enough 20-60 seconds?  and require payments to add a mining fee,  you can be reasonably sure the tx will be the one mined, and go ahead and say, " even if it is double spent I will get the confirmation "

that's the idea anyway.

i would agree that any system like this can not say with 100% certainty that it will get confirmed no matter what. but it should make almost all 0 conf. double spend attempts nearly impossible.

I wasn't aware of this can you point to where I can read up on this?


If it pays a proper fee and is broadcast first the probability is high that this tx will get included in a block. As far as I'm aware, the probability is in your favour but there is still a chance, albeit small, that it will be double spent.

In the end we if we can come up with a set of rules to accept 0 conf payments with very little risk, that would be very good news for bitcoin payments in person.

Sure, copy the persons photo ID. Limit sales to values that you'd be comfortable losing to shoplifting. Done.

For example, say I want to potentially pay you up to 10 BTC later.

I write a transaction paying 10 BTC to a multisignature output that requires me+you.  Without broadcasting that payment, my software contacts your software and asks it to sign a refund transaction which pays the 10 BTC back to me, but locktimed two weeks from now.  After you give me that signature I announce the payment into the escrow.

Now for the next ~2 weeks I can pay you up to 10 BTC out of those funds instantly, with no reversal risk for you.

The restrictions: Funds are locked up, and I have to know who I'm possibly paying in advance.

If there is some third party that many people trust to not double spend "you" in this protocol could be replaced with the third party to instead relax the requirement that I know who I want to transact with in the future. (e.g. "anyone who trusts Theymos to not doublespend").

we can do better then that...

simple rules, tx must have a fee, and look for double spend for 30 seconds, and you appear to have pretty damn good protection, even if a double spend is initiated.

asking for ID, and taking on the risk in full, is a crappy solution.

we have near perfect information as to all TX on the network at all times, let us use it!

There's a lot of bakeries and coffee shops out there that have found they can go as far as not even having any staff on duty during the day and relying 100% on the honesty of their patrons to actually pay them. One example: http://www.theglobeandmail.com/life/coffee-cookies-but-no-cashiers/article1058362/

Another example is how in many places newspapers are sold in unlocked containers with a slot to voluntarily drop a quarter in. Or for that matter how it's routine for campgrounds and huts in mountainous areas to be unstaffed with just a drop box to collect fees from hikers. Huts are a funny example: parks often find it cheaper to leave them unlocked entirely year-round than to replace windows broken by people who forgot their key or combo, or were in an emergency and needed the shelter.


Here's a better solution that expects nothing more from all parties than rational economic self-interest: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189

Okay - but f you don't pay then do I need to do anything to stop the repayment (am just trying to clearly see how it gets completed without any race condition)?

Its good to know, (atho not surprising), that people are dreaming up solutions to this problem.
but the proposed solution requires some rewrite of the underlying protocol, this method does not, and it dead simple.

the actual effectiveness of this solution is unknown to me tho.

if i require a mining fee, and checked for 30-60 seconds that you didn't try to double spend, before accepting your 0 conf BTC payment.
could you double spend, and have the double spend confirm, before the orginal tx. ( provided you don't have any  hashing power...)

I can't decode your question. Can you try asking another way or perhaps give an example?  There should be no race condition, so long as the the refund is far enough in the future that you can reliably get the legit spend in before it locks.

+1

There are inherent risks in all in-person transactions ranging from counterfeit banknotes to unwarranted chargebacks, stolen cards, etc.

No one is realistically going to orchestrate a double-spend or MitM attack to get a free coffee at starbucks, or even a free TV at walmart. Even in the extremely unlikely event they somehow succeed, the criminal (fraudster) has likely been caught on security camera and it's no different than any other fraud/shoplifting event.


Yes, that's a 99%+ workable solution in almost all cases - "perfect is the enemy of better" (or however that saying goes).

Don't assume that double-spending is hard: https://blockchain.info/create-double-spend

Even "check the tx has been broadcast" schemes don't work all that well because it's easy to craft transactions that some % of the hashing power will ignore, (like satoshidice bets or the negative nVersion bug) and double-spend those transactions with transactions that they aren't ignoring. Even double-spend alerts don't help here, because the attacker can just wait until they've left the shop/downloaded the file/whatever to broadcast the double-spend.

Things like security cameras and careful monitoring of losses is the way to go.

Maybe I've missed something but if you are holding a valid refund tx. then how is that *disabled* to ensure the funds can no longer be restored (or is that the escrow part)?

By spending the funds out from under it before the refund transaction becomes valid. The refund is nlocktimed so that it will not be valid until the sufficiently far future.  If you get too close to the refund time then there is a possible race and any payment out of the escrow shouldn't be trusted without confirmations.

The refund exists just to prevent the other party from attempting extortion or in case they get hit by a bus... but its locked and not valid until the future. Normally you wouldn't use it... you'd pay them from the escrow, which is safe because it needs their signature too. If you pay them less than the full value of the escrow either the rest is returned to you or paid into a new escrow (which you also get a refund transaction for before announcing).

Okay - thanks - got it now.

I still don't see how someone standing at a till can broadcast a double spend.

Some risk analysis would need to be done.

Some assumptions:

Value of transaction likely small
Shop has own centralized bitcoin server which is very well connected.
Shops own infrastructure used to create and broadcast transaction (customer doesn't send via his phone etc.)

For larger transactions $100-$500 (super markets, clothes shops etc) To mitigate the risk, maybe the customer can pay first then is refunded or charged more after the items are scanned. A big cart of groceries could easily take 10 mins. Or if you're standing in line.

Then you aren't thinking with an adversarial mindset.

The person standing at a till is running a special "deluxe doublespender" wallet, that automatically attempts to double spend every transaction they make according to appropriate preconfigured parameters (like delays, connections to known miners, fees, etc).

And sure, there are plenty of things you can do to cope with or mitigate the risk.  None of them, however, begin with being anything less than completely frank about what the risks are.

If a TX (with a higher miner's fee) is broadcast, most current miners will prioritize it and queue it up sooner than the smaller fee one, even if it comes much much later.

If a miner is in collusion with the attacker, by sharing the transaction privately with him, he can simply excuse himself as: I have included one transaction that was valid and correctly prioritized while this person you are referring to as the attacker tried to double spend so there is no way to prove I was involved.

There is a chance of 100% - (100% * miner_hash_power / network_hash_power) that this transaction can be cancelled after being "confirmed-by-owner". For example if the miner is BTC Guild, then 1 in 3 transactions can be reversed under your recommendations.

By changing the bitcoin protocol, there is however an option to incentivize and guarantee that it is better for the miners to act fair than to act covertly. If you are interested in knowing the method (PM me), the "confirmation" period for such a transaction will have an average of 38 seconds and an incentive to force miners to respect transaction age as a meaningful parameter. You can "confirm-by-owner" or "confirm-by-miner-paid-by-owner" before a block is created that includes the transaction.

Thats not true. I don't believe any miners today will accept a later _conflicting_ transaction even if it has a higher fee, except by accident (e.g. restarting their nodes at just the right time).

Some people argue that eventually some miners will do this because its obviously the greedy-rational optimal behavior, and further that because some miners will do it that it should be the default for all in order to reduce avoid incorrect expectations and to facilitate the fee burning solution to double spending.  This argument hasn't yet convinced everyone.

Agree completely. Being frank about the risks would include assigning probabilities to them and adjusting them over time based on empirical realities, just like card processors and insurance companies do.

One of the main reasons internet commerce took 5-7 years to gain any traction in the 1990's was mass media continually going on about how dangerous using credit cards on the internet was supposed to be. There was a mass misperception that card numbers could easily be stolen 'in transit' while being sent on the internet.

One problem: According to VISA at the time it never actually happened, not even once. Sure, card numbers could be taken from poorly secured merchant servers, retail merchant skimming, etc. but not once was a card number ever shown to be compomised 'in flight'. Anyway, this largely baseless paranoia did provide an excellent start-up environment for Paypal (so you wouldn't have to share your card number with anyone else) and forced the card companies to limit unauthorized-use liability to $50 or so to allow customers to feel safe using them online.

The risks associated with zero-confirmation retail transactions with bitcoin are probably lower (or at least similar) to those associated with credit cards, but the lower fees would probably outweigh any additional risks anyway:

Example:
Someone walks into your cafe in the US, orders a coffee, pays $3 using blockchain. Risk of DS <1%, fee = 0
Someone walks into your cafe in the US, orders a coffee, pays $3 using VISA. Risk of stolen card/chargeback <1%, 3-5% fee

A guy wearing a lulzsec hoodie walks into your TV-store in Bulgaria with a friend, both fidgeting with their phones. They're in a hurry and want to buy a TV with bitcoin. You say no, we only take cash today (in Bulgarian, of course.) Risk of DS = 0  ::)

 
 

How can you prove they preferred one or the other transaction? You can't!

Anyone can broadcast two transactions and then falsely blame the miners for helping him double-spend, but in the end, we just see one failed double-spend attempt, nothing much.

I've helped users many times with self-doublespends when they have stuck transactions that aren't confirming in a timely manner due to low fees. If miners were accepting higher fee replacements these issues wouldn't exist. So I'm quite confident that at the moment they aren't.

I've also never seen a complete patch to produce this behavior and as far as I can tell very very few miners today write their own software.

That sounds good. Then does this thing work or not: https://blockchain.info/create-double-spend

Yes, there is something called off-the-blockchain transactions. You don't need confirmations to send and receive Bitcoin off of the blockchain, so you don't have any risk as long as the off-the-blockchain service doesn't run with your coins.

I think I mentioned risk analysis.

Would this strategy work?  Naturally, it isn't without its own flaws either.

Say you're going to starbucks for a coffee.  On your way, you "prepare" your payment (as in the same escrow strategy that gmaxwell suggested), but in a different manner:

Starbucks publishes via a standard URL (say, https://starbucks.com/pubkey) the EC point -- the public key -- to a secp256k1 private key.  The key could change all the time, daily, whatever, that's up to starbucks. Then, you generate another private key, computes the EC point, adds the EC point to starbucks's, then hash that public key to obtain a bitcoin address. You prepare your payment by sending some coins to that address and broadcast the transaction.  Neither you nor starbucks can spend the coins right now.

You may realize that this is split-key address generation, like how vanitygen bounties work.

So you arrive at starbucks, and place your order.  To make a payment, you give starbucks the private key you generated, starbucks can instantly verify that the private key was the correct one and leads to the address you sent coins to earlier and that the coins are confirmed. It's impossible for you to spend those coins because you don't have the other half of the private key.  Along with your private key, you give starbucks a "change" address, they build a transaction sending the prepared coins (minus coffee price) to your change address and they broadcast that transaction, or just give it to you to broadcast.  They don't have to wait for confirmation, they *know* you can't spend the prepared coins.

Suppose you never made it to starbucks and want your money back - you hop onto https://starbucks.com/refund, give them your private key and change address, and they send you back your coins.

I think the cons in this situation are better than the escrow/timelocked version, since you can get your coins back immediately (as long as the vendor is cooperating). The vendor has to be trusted to send you proper change, but I think that's less of a big problem since the vendor has more to lose by cheating you.

You could consider this strategy like purchasing a gift card but getting your change in currency.  You also have the option to return the giftcard completely and don't have to lock away coins using nLockTime.

Thoughts?

Sorry, starbucks was run by Bernie Madoff and won't return your money. Basically under your scheme: Once you've given them the secret key for the refund they can say "HA HA, mine now!", and even without you giving them the key they can freely extort you ("Give us the key, or we're not talking. Maybe if you give it to us we'll give you back 10%") with no finical loss.

The escrow/timelock version can give you your coins back immediately if the vendor is cooperating too. The timelocked refund is just there to prevent extortion like "No, sorry, I won't refund your coins unless you give me at least half." or to deal with the vendor getting hit by a bus.

Certainly there are cases where you reasonably can trust the vendor, but in most of those you can probably go all the way to a premature payment and dispense with the split key stuff.

How is this different than handing the starbucks cashier a 100$ bill and oops, he only saw a 10$ bill?

Yes, this scenario involves a layer of trust -- I don't deny that -- but we aren't talking about 100,000$ purchases.  If starbucks defrauded one customer, no other customer would play.  They have a lot to lose by cheating the customer.


True, I had also considered a strategy for building your order before arriving, sending payment (sure, split key or multisig could work here too) and delivering the private key for instant payment.

Please read the last line of my above post.

Here is one solution to the 0 conf problem, not sure how viable/practical/feasible it is. It's probably been proposed before, and [may] require an Oracle.

When checking out, two transactions are created by the payer instead of one. The first tx (0-conf) is broadcast immediately by the payer, for amount x. The second tx is broadcast (as a fidelity bond) and given to the Oracle. This second tx spends x amount, but it spends different coins in the payer's wallet.

If the Oracle sees that the coins are double spent or somehow didn't make it to the merchant, the fidelity bond is triggered and the coins from the second tx are broadcast to the merchant. If the original tx is confirmed, the funds from the second tx are returned to the payer.

Obviously this method kinda sucks, because it requires you to have twice the amount of Bitcoins you want to spend. In POS scenarios where you may not be spending huge amounts (e.g. buying a stick of gum) this could be useful. please debunk

edit:nm, peter todd has a more robust version of this: http://sourceforge.net/mailarchive/message.php?msg_id=29185108