Ok, but seriously how will I pay for my $250 grocery bill with bitcoin?

[cypherblock]

So really, how do brick and mortar merchants accept bitcoin payments in 1 second or less without risking double spending? Do we actually have a solution for that which doesn't require me (and merchant) to use a proprietary bitcoin app but let's me use a generic wallet app?

I wouldn't be surprised, but haven't checked, if Coinbase or somebody has a solution for this, but I'm guessing it requires both merchant and customer to be using Coinbase.

I guess if the larger bitcoin firms like Bitpay, Coinbase, etc provide guarantees to merchants that the transaction will be confirmed and they take the risk of fraud (double spending attacks) then that is certainly one solution.  They can quickly (1 second?) do a check to make sure transactions look ok (based on current blockchain) and hope that double spending attacks will be rare.

[1715014969]

1715014969

[1715014969]

1715014969

[zvs]

I've never used one of those online wallets, but they don't provide you the private key, do they?  So essentially they're providing a service to you (the wallet) while retaining complete control over it.

Unless the security of the site itself was compromised, then there wouldn't be any issues..

[TimS]

I've never used one of those online wallets, but they don't provide you the private key, do they?  So essentially they're providing a service to you (the wallet) while retaining complete control over it.

Unless the security of the site itself was compromised, then there wouldn't be any issues..

(speaking of Coinbase, at least) Yep, you're right: they don't give you the private keys to the money in your balance, so they should be able to provide no-risk transactions (at the cost of trusting Coinbase with your coins) if you and the merchant both have accounts there. Imported private keys might be an exception to that (I don't know if they only sweep them, or let you keep a balance on them).

[cypherblock]

I've never used one of those online wallets, but they don't provide you the private key, do they?  So essentially they're providing a service to you (the wallet) while retaining complete control over it.

Unless the security of the site itself was compromised, then there wouldn't be any issues..

Right, but coinbase was just an example in this case of a larger firm providing services to both merchants and the general population. Yes they generally sweep your bitcoins into their own accounts and in fact use their internal accounting to know who owns what. When you spend coins from coinbase they have to first send a transaction from their hot wallet to your wallet, then from your wallet to whomever you are sending to. But they don't really have to do it that way. I think Blockchain.info let's you keep control of your keys and coins while providing on online wallet.

[jambola2]

Well , I see an inputs.io lookalike as the best solution.
It permeated almost all the Bitcoin websites and it had off-chain transactions.

But the problem is , the inputs.io scare has put everyone off the idea for a loooong time.

Your idea is interesting , but on-chain transactions can not happen under 10 minutes.

[piotr_n]

There used to be this concept of green addresses. And now with multisig you can even have a similar service without the risk for the coin owner to get robbed by the green address provider, though at the expense of bigger transactions and thus higher fees.

But in general, you should know that bitcoin has not been designed to support fast payments.
People who think that Bitcoin can do such things have been deluded.

Bitcoin is much faster than most of the irreversible payment methods known before (e.g. bank wires), but it has never been meant for instant payments.
Although it provides a solid base for a possible instant payment services that would be developed over the bitcoin protocol.
I general, what you need for instant payments is some kind of a central authority, an insurer which the parties accepting payments would trust.

[instagibbs]

On-chain solutions like greenaddress.it's 2-of-2 signing allow 0-conf transactions, provided the merchant trusts ga.it not to double-spend.

[onemorebtc]

i like the othercoin idea.
basically it allows offchain spending of bitcoins

edit:
https://bitcointalk.org/index.php?topic=321085.0
https://bitcointalk.org/index.php?topic=319146.0

[cypherblock]

Well , I see an inputs.io lookalike as the best solution.
It permeated almost all the Bitcoin websites and it had off-chain transactions.

But the problem is , the inputs.io scare has put everyone off the idea for a loooong time.

Your idea is interesting , but on-chain transactions can not happen under 10 minutes.

I'm not familiar enough with off-chain transactions, or the inputs.io debacle,  but starting to look at it (I'm a bit late to the party I know). Found an old post http://gavintech.blogspot.com/2012/07/off-chain-transactions.html from Gavin Andresen (possibly pre-dating inputs.io) about it, so reviewing now.

Anyway, not sure if off-chain is really the answer but we need some way for more instantaneous transactions. Multi-sig may have the answer there somewhere.

[CatheryneN]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

[onemorebtc]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

i dont think any p2p-blockchain can handle the volume if many people use it for buying groceries.

so i see huge value in secure (less then blockchain itself but still secure) offchain transactions.

edit: to clarify: only trustless one which only requires trust in my card (or key or whatever). not a second inputs.io

[AmDD]

As a merchant you should feel safe accepting a transaction the moment you are able to see it on the network. The amount of hashpower a user would need to control in order to double spend is going to cost WAY more than the $5 coffee you are trying to buy. And even if they did somehow control that much power (hacking a pool or similar) they will probably go after a much larger transaction to make it worth their time and in that case, for a large transaction, I would be willing to wait 10-30min for a few confirmed blocks. Buying a house, for example, isnt a process that can be done in 3sec or less anyway. So once you send the Bitcoin and fill out all the paperwork and do the inspection, the whatever.... you will have plenty of confirms saying the coin is in your wallet.

I really think people are too wrapped around the "6 confirms" thing.

[DeathAndTaxes]

In the short term the solution is probably you register your CC with the grocery store and then they let you pay w/ Bitcoins zero confirm.  If you pull a double spend then just charge your CC the amount plus a penalty.   It would be no more risky than accepting CC directly and saves the store the CC fee on most transactions.

[Peter Todd]

As a merchant you should feel safe accepting a transaction the moment you are able to see it on the network. The amount of hashpower a user would need to control in order to double spend is going to cost WAY more than the $5 coffee you are trying to buy.

I suggest you spend some time playing with my replace-by-fee tools, especially the doublespend.py script. Double-spending zeroconf transactions is really easy.

[AmDD]

As a merchant you should feel safe accepting a transaction the moment you are able to see it on the network. The amount of hashpower a user would need to control in order to double spend is going to cost WAY more than the $5 coffee you are trying to buy.

I suggest you spend some time playing with my replace-by-fee tools, especially the doublespend.py script. Double-spending zeroconf transactions is really easy.

Maybe Im mistaken.... I'll have a look at these. Any other info on the topic, I dont want to derail this thread...

[Newar]

It may not be bitcoin that makes it safe, but reality.

If you try to double spend at a supermarket, that would probably be your last visit there since they now know your face, there's CCTV etc.

[piotr_n]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

I think the "another Paypal" solution is exactly what you want here.

The only difference is that this paypal would also provide anonymity and non-reversibility of transactions.
You could create an account there without providing any personal data, possibly even from behind Tor.
The service doesn't care who you are because it does not need such knowledge. It is there to provide instant payments using the coins you first deposited there.

And this approach could also address the transaction volume size.
Because the service does provide insurance for non-confirmed bitcoins transactions, but bitcoin trasnactions will eventually become expensive so the merchants will have an incentive to get single bills paid not through the chain, but "internally". And only withdraw it like once a day.

Of course a decentralized solution for off-chain transaction would be much better, but it is also a much harder problem to solve, so IMHO centralized solutions that focus on anonymity will come out first as more popular (just like centralized black markets or centralized mining pools have).
There is no reason why a service like Bitcoin Fog couldn't be turned into a payment processor - they already have good privacy protection infrastructure and only need to start supporting internal transfers between accounts.

Of course the governments will not like it and their minions will quickly attack the idea all over, using all kind fo cheap propaganda, but who cares about these dicks anyway.

[jambola2]

Well , I see an inputs.io lookalike as the best solution.
It permeated almost all the Bitcoin websites and it had off-chain transactions.

But the problem is , the inputs.io scare has put everyone off the idea for a loooong time.

Your idea is interesting , but on-chain transactions can not happen under 10 minutes.

I'm not familiar enough with off-chain transactions, or the inputs.io debacle,  but starting to look at it (I'm a bit late to the party I know). Found an old post http://gavintech.blogspot.com/2012/07/off-chain-transactions.html from Gavin Andresen (possibly pre-dating inputs.io) about it, so reviewing now.

Anyway, not sure if off-chain is really the answer but we need some way for more instantaneous transactions. Multi-sig may have the answer there somewhere.

Well , that post is an awesome idea , requiring lesser trust.

Inputs.io was one of the systems that required complete trust.

You send your coins to Inputs.io , and they write down a balance for you. You can send your coins to other users of that service for low or negligible fees , as the Bitcoins are not really transacted but just the inputs.io records are changed.

You would be charged only when you withdraw , which covers the fees for transferring your inputs.io funds to an external wallet.

I have to say though , inputs.io worked remarkably well , even though it was centralized. Sadly though , it got hacked (or some say it was a man-in-the-middle attack) and the Bitcoin community is not likely to trust something similar again.

[kjj]

If only there was some way to establish a network of transaction-risk management companies to assist in cases like these...

[Carlton Banks]

There is of course the option to lower the block interval, perhaps using Litecoin's code, or developing a different solution to minimise orphaned blocks. I don't like that idea much, there seem to be hard limits to the range of improvement.

Perhaps the POS could accept payment only from devices that sign transactions via RFID (the putative Sigsafe, for example). This would require more sophisticated/expensive attempts at double spend attacks, and so the economic sweet spot for such a trade-off could move into a range where the value of the transaction is worth waiting for 1 confirm anyway.

Another would be to use an ID protocol as a part of the purchase. You shouldn't necessarily be forced to give personal details, just allow the shop to verify and record an ID token that you carry the key for on your mobile phone. The staff verifies the ownership and checks the amount you paid/sacrificed for the ID, then decides whether that's good enough surety for the circumstances and permits a zero-conf.

[AmDD]

What about merchants just accepting the risk? They do that now with cash, check and credit cards. People print and use counterfeit money everyday, people write bad checks and use stolen credit cards. The thing is not everyone does this. The few bad transactions that will happen are just part of the risk of having a business. Granted eliminating that risk would be great but how much effort is it worth?

[piotr_n]

What about merchants just accepting the risk? They do that now with cash, check and credit cards.

How do they accept the risk of double spending with cash? There is no such risk.

The idea is to make bitcoin payments equally reliable/irreversible, for the payees, as the cash payments are.
If they get to "accept the risk", they can just as well put the bill on you tab and let you pay it from your desktop after you get home.

[capsqrl]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

I think the "another Paypal" solution is exactly what you want here.

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain. Each user would sign up for service on their operator of choice, and keep a relatively small spending balance. There would be a standard protocol for payments and settlements that anyone could implement, and merchants wouldn't have to support any particular operator such as CoinBase.

This would be for harmless, non-controversial, everyday humdrum use-cases like buying groceries or cups of coffee. People can yell all they want about this violating the sacred intention of the blockchain as a public ledger, but in fact every cup of coffee ever consumed does not need representation on the blockchain. The blockchain is still there for anyone who is unable or unwilling to use the off-chain network (think controversial or illegal transactions, long-term or high-volume storage, privacy).

[murraypaul]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

I think the "another Paypal" solution is exactly what you want here.

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain. Each user would sign up for service on their operator of choice, and keep a relatively small spending balance.

We could call them ... banks.

[capsqrl]

We could call them ... banks.

We could call them aeroplanes for all I care; they're useful and don't negate any advantage of Bitcoin for anyone who don't want to use them. In fact they could facilitate more private transactions since they're not expressed on a public ledger, while allowing Bitcoin to scale.

[cypherblock]

On-chain solutions like greenaddress.it's 2-of-2 signing allow 0-conf transactions, provided the merchant trusts ga.it not to double-spend.

I think you are right about this. So if I understand correctly it can work as follows:

First, before I go shopping,  I send some bitcoins to a 2 of 2 multisig address between me and some 3rd party service. TX1

After that transaction is confirmed (standard 6 or more blocks deep in the chain), any merchant that also trusts that 3rd party service not to double spend can receive "instant payments". As follows:

I show up at merchant store (or website), I buy stuff and for payment: I send a message to the 3rd party service with my signature for TX1 and ask them to sign it and send payment to the merchants public address (that they've provided me). This could be done either through my wallet or the merchants wallet/pos but it is done 'offline' in the sense that this message is not sent to the bitcoin network yet since it needs the 3rd party signature.

3rd party service checks their own system to make sure that they've received no previous attempt to spend TX1 and then creates a transaction spending TX1 (TX2) by adding the second signature needed.

Merchant can get sent a copy of TX2 and does not really even have to wait for one block confirmation. They trust 3rd party and know that 3rd party will not double spend.

I think this how greenaddress.it is doing it? Yes.? They also use the nLockTime parameter, so that TX1 will 'expire' after some time so that I can get my coins back if 3rd party goes bankrupt or doesn't release payments when requested, but I haven't got my head around that part yet (as haven't looked into nLockTime yet).

[instagibbs]

I think this how greenaddress.it is doing it? Yes.? They also use the nLockTime parameter, so that TX1 will 'expire' after some time so that I can get my coins back if 3rd party goes bankrupt or doesn't release payments when requested, but I haven't got my head around that part yet (as haven't looked into nLockTime yet).

They send the change to a new multisig address, and send you a new refund txn that you can't spend for "90 days" or something(1440 blocks? It says in the app). So if ga.it disappears tomorrow, you have to wait a bit to get your money back, but they can't run away with it.

The normal workflow is exactly the same as regular wallets that have 2FA. It's just that their servers sign the txn when you respond to the 2FA challenge.

FWIW, it's the only wallet I'm using these days, outside of paper wallets. Great for my spending money. They are rolling out 0-conf stuff as we speak, which uses the payment protocol.

[piotr_n]

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain.

Certainly, there should be a competition, but I would not go into banking kind of infrastructure, because then when one of them runs away with money, the entire system collapses. Just like the one we are now seeing collapsing

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

So:
* Being a merchant, to accept payment from a new "bitcoin paypal provider", you just need to create a merchant account there and add it to your billing system (POS).
* While being a payer, you need to create a customer account at a "bitcoin paypal provider" of your choice and deposit some bitcoins there.

Mind that each of these providers would give you a different kind of security/anonymity/fees/etc.
For instance: some of them can even credit your payments, though definitely not those which did not check your ID.
And that is great - because you have a choice.
That is pure market and that is how it should work.

Of course the payment providers/processors/insurers (aka "bitcoin paypals") can come out with a system allowing off-chain transactions between them.
But that would not be a requirement and such systems would rather be transparent for the users, and the merchants.
As long as the balance on our account is correct, we don't really care about how the corporations settle their balances between each other; on- or off-chain.

[capsqrl]

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

You make a good point, and I certainly don't want to see the necessity for bail-out funds etc when one node in the settlement network goes under. I like your alternative, and it's probably more realistic, but I'm afraid it would create a much smaller ecosystem, perhaps tending towards a duopoly or worse, like one "Visa" and one "Mastercard". I want a rich ecosystem of actors competing against each other on fees, security, features etc.

[piotr_n]

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

You make a good point, and I certainly don't want to see the necessity for bail-out funds etc when one node in the settlement network goes under. I like your alternative, and it's probably more realistic, but I'm afraid it would create a much smaller ecosystem, perhaps tending towards a duopoly or worse, like one "Visa" and one "Mastercard". I want a rich ecosystem of actors competing against each other on fees, security, features etc.

That is why you want each of these paypals to provide you with different kind of services - that is going to make the difference.

Not everyone needs a Tor level anonymity and a highly secured con mixers - but some do and they will be willing to pay for it.
Such kind of providers might not be accepted by all kind of merchants, but can still use the same API.

At the other hand, if you provide a bitcoin paypal with your photo ID and a credit history - they may like to build their business model not as much on transaction fees, as maybe on crediting your payments, assuming you'd want to borrow some coins from them at the interest.

BTW, both of the above mentioned business models are evil for some people.
The first one feeds on a money laundering - the second on usury...
But none of them is evil for me, especially when people have the choice between them.
Not to mention that there would always be business models in between.
Still there is no reason why the API could not be common for all of them.

[ajareselde]

Simply, coinbase should be the third parity escrow like service.
You would be confirmed in the same amount it takes you to put in your PIN for CC.
also,did you ever buy something using bitpay ? it is confirmed in no-time

[joshraban76]

I thought about something, maybe printing GC like voucher and stated on it the BTC price along with it's corresponding USD.

Or printing a voucher by $300 for example, and the remaining will be sent to you automatically to your wallet.

[Lethn]

https://coinkite.com/

[cypherblock]

On-chain solutions like greenaddress.it's 2-of-2 signing allow 0-conf transactions, provided the merchant trusts ga.it not to double-spend.

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? This has been proposed before, and was just having discussion with someone from Bitsimple on this (they suggested it). They were saying you as a merchant or more likely a service the merchant is using, can deploy a bunch of nodes across the globe (not a huge number, but maybe 10-50). Merchant get's your transaction and does wait like 10 seconds, but no more. If any of the service's nodes see a second transaction trying to spend the same bitcoins, it notifies the merchant POS/wallet system. If no second transaction is seen in 10 seconds it is considered 'safe'.

This could eliminate the need for the buyer to use a 3rd party like greenaddress.it and only the merchant would have to use a service that offered this protection.

[nwfella]

Well , I see an inputs.io lookalike as the best solution.
It permeated almost all the Bitcoin websites and it had off-chain transactions.

But the problem is , the inputs.io scare has put everyone off the idea for a loooong time.

Your idea is interesting , but on-chain transactions can not happen under 10 minutes.

I cringe everytime I so much as see the name inputs.io or tradefortress or infested_with_bugs or whatever the hell his name is now.  But yes, something that could have that much market penetration but 100% decentralized in it's design.

You put enough power into the hands of any one single individual and unless that person is Ghandi, or Mother Theresa or something they will more than likely eventually succumb to greed.

[coastermonger]

So really, how do brick and mortar merchants accept bitcoin payments in 1 second or less without risking double spending? Do we actually have a solution for that which doesn't require me (and merchant) to use a proprietary bitcoin app but let's me use a generic wallet app?

I wouldn't be surprised, but haven't checked, if Coinbase or somebody has a solution for this, but I'm guessing it requires both merchant and customer to be using Coinbase.

I guess if the larger bitcoin firms like Bitpay, Coinbase, etc provide guarantees to merchants that the transaction will be confirmed and they take the risk of fraud (double spending attacks) then that is certainly one solution.  They can quickly (1 second?) do a check to make sure transactions look ok (based on current blockchain) and hope that double spending attacks will be rare.

Coinbase and eGifter facilitate your ability to purchase groceries quite nicely.  Coinbase is a place that lets people easily acquire BTC, and eGifter is working to let people spend it basically anywhere, even in places where the merchants don't know about BTC.  Let's assume you have the eGifter app and a Coinbase account, and need to buy $200 worth of groceries.

1.) Shop for some food at Walmart.
2.) You can buy a walmart giftcard straight from the eGifter App using bitcoin.
3.) Egifter gives you a whopping 6% discount, which means you paid $188 for your $200 Walmart Giftcard.  (why can they do this? Because BTC doesn't charge back)

[Gianluca95]

Use BitPay to make your transaction with any problem and then pay grocery bill !

[cypherblock]

Coinbase and eGifter facilitate your ability to purchase groceries quite nicely. 

So you didn't really address the questions about 1 second checkouts that are guaranteed or safe. But you did successfully promote those 2 services if that was your intent.

[luckypyrate]

It seems to me that, while your question is valid, it is no different than real world situations now where people are using checks and such for transactions.  I mean really only just now are grocery stores doing realtime verification of funds with checks.  Not to mention if the credit card network or the sites internet goes down, a lot of these retailers have their CC machines set to batch automatically until a connection is restored in order to maintain continuity of business.  A couple of crooks got off well, albeit briefly, with this little secret by putting tin foil on the satellite receivers and then buying up gift cards in the store and then removing the foil once they left.  They made off with upwards of $300 a store and none-the-wiser until several weeks later. 

My point is these fears have existed throughout commerce history, and it really just comes down to a level of expectation of honor and also a little bit of insurance against such attacks.  I think the eBay model of financial ostracism for suspicious or fraudulent buyers/sellers works really well for them and on a larger scale could work really well in a bitcoin aware world. 

Just some thoughts...

[Brangdon]

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? This has been proposed before, and was just having discussion with someone from Bitsimple on this (they suggested it). They were saying you as a merchant or more likely a service the merchant is using, can deploy a bunch of nodes across the globe (not a huge number, but maybe 10-50). Merchant get's your transaction and does wait like 10 seconds, but no more. If any of the service's nodes see a second transaction trying to spend the same bitcoins, it notifies the merchant POS/wallet system. If no second transaction is seen in 10 seconds it is considered 'safe'.

It would help further if nodes that detected double-spends either relayed them, or, better, relayed an alert that a double-spend was being attempted.

[bitcoinbeliever]

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? ... If no second transaction is seen in 10 seconds it is considered 'safe'.

It would help further if nodes that detected double-spends either relayed them, or, better, relayed an alert that a double-spend was being attempted.

Good questions.  Everyone sees that the decentralized bitcoin system can't have complete, immediate protection from the effects of 0-conf double-spends, but that is totally different from saying that the situation cannot be improved immensely.  Some improvements that can be made are:

1 - Agree that 0-conf double spends should be made more difficult, not easier (there are actually people who disagree).
2 - Per inner quote above, wallets should immediately and loudly notify their users of double-spends.  Amazingly, I am not aware of a single wallet that does this!  Please post if I am missing one or more.  The reason you notify the user is that they may not yet have handed over the merchandise.
3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.
5 - Longer-term, before giving up on the bitcoin protocol, we should ask how to incentivize miners NOT to include second-spends in blocks.  For example, I have never seen a reason why this idea from 2011 could not reduce the unsafe period for 0-conf double spends to only seconds, instead of many minutes https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484

[onemorebtc]

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? ... If no second transaction is seen in 10 seconds it is considered 'safe'.

It would help further if nodes that detected double-spends either relayed them, or, better, relayed an alert that a double-spend was being attempted.

Good questions.  Everyone sees that the decentralized bitcoin system can't have complete, immediate protection from the effects of 0-conf double-spends, but that is totally different from saying that the situation cannot be improved immensely.  Some improvements that can be made are:

1 - Agree that 0-conf double spends should be made more difficult, not easier (there are actually people who disagree).

i disagree...
i dont like false security measures which give people the impression something is safe when it is not.

and i still hope for the feature to resend a tranaction with a higher fee if it gets stuck

2 - Per inner quote above, wallets should immediately and loudly notify their users of double-spends.  Amazingly, I am not aware of a single wallet that does this!  Please post if I am missing one or more.  The reason you notify the user is that they may not yet have handed over the merchandise.

right, i'd love that feature as well

3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.

no, this is to easy to use for spamming the network with transactions.
but maybe we can use an overlay network for that?

5 - Longer-term, before giving up on the bitcoin protocol, we should ask how to incentivize miners NOT to include second-spends in blocks.  For example, I have never seen a reason why this idea from 2011 could not reduce the unsafe period for 0-conf double spends to only seconds, instead of many minutes https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484

not sure.... dont think its possible at all to make it safe as the attacker does not have to publish his double spend attempt before the fact - only his miner needs to know it of course

[/quote]

[Altoidnerd]

What about just prepaying BTC for later use?  I do this all the time on e.g. namecheap.  I'll spend the credit eventually, I don't really mind.  I understand the merchant's needs.

[Brangdon]

3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.

As long as the double-spend is relayed in a way that no-one will confuse with a single-spend. They shouldn't be relayed as a normal transaction.

Possibly the alert should embed both transactions. That makes it a neat, clear-cut proof of attempted fraud in a single message. Then again, normally the alert is being sent to the same nodes that the original transaction was relayed to, so perhaps that's not necessary.

no, this is to easy to use for spamming the network with transactions.

Only the first double-spend needs to be relayed; subsequent ones can be dropped because a single double-spend transaction is enough to establish that a double-spend attempt is in progress and alert the merchant. So spamming is limited.

If you want to limit it more, only relay/alert double spends if the amount is, say, at least triple the current dust level. So a spammer can either send a million transactions with 5431 satoshi each, or 333,333 with 16293 satoshi each plus 333,333 "free" double-spends alerts. The cost to the spammer is the same, as is the bandwidth cost to the network. (And the double-spends don't get added to the block-chain so we gain there.) In practice, 16293 satoshi is small enough that thieves aren't going to bother trying to double-spend it, and most merchants can accept the risk that they will.

(We can juggle the numbers depending on the actual cost of the alert, and whatever the dust level is nowadays, but you get the idea.)

[zebedee]

When I were a lad, the question was "But seriously, how will I pay for my $25 grocery bill with bitcoin?"