alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

I agree with Mike & Jeff. Blowing up 0-confirm transactions is vandalism.

bitcoin transactions are all probabilistic. there is a small chance 1-confirm transactions can be reversed, and a different but also usable chance that 0-confirm transactions can be reversed. I know 0-confirm is implemented in policy and not consensus, but it provides fast transactions and a lot of the current ecosystem is using it for low value transactions. why would anyone want to vandalise that.

to echo Mike bitcoin itself kind of depends on some honest majority, we can otherwise get to situations soon enough where its more profitable to double-spend than mine honestly as subsidy drops and transaction values increase even without 0-confirm transactions. subsidy doesnt last forever (though it lasts a really long time) and even right now if you involve values that dwarf subsidy you could make a "criminally rational" behaviour that was more profitable. we even saw 0-confirm odds-attacks against satoshi dice clones. but if we assume the "criminal rational" model, its a is a race to the bottom logic, and bitcoin is already broken if we have someone who wants to go for it with high values. that'd be scorched earth also.

(I read the rest of the arguments, i understood them, I disagree, no need to repeat in reply.)

So how about instead, to be constructive, whether you agree with the anti-arson view or not, lets talk about solutions. Here's one idea:

We introduce a new signature type that marks itself as can be spent by miners if a double-spend is seen (before 1-confirm.) We'd define a double-spend as a spend that excludes outputs to avoid affecting valid double-spend scenarios. And we add behaviour to relay those double-spends (at priority). We may even want the double-spend to be serialisation incomplete but verifiable to deter back-channel payments to pretend not to receive one, in collusion with the double-spending party.

Now the risk to the sender is if they accidentally double-spend. How could they do that? By having a hardware or software crash where they sent a tx but crashed before writing a record of having sent it. The correct thing to do would be to transactionally write the transaction before sending it. Still you can get a fail if the hardware irrecoverably fails, and you have to resume from backup. Or if you run multiple non-synced wallets on the same coins.

Typically if you recover from backup the 1-confirmation window will have passed so the risk is limited.

The feature is opt-in so you dont have to put high value coins at risk of failure.

(Its related to the idea of a one-use signature, where two signatures reveals a simultaneous equation that can recover the private key; except here the miner is allowed to take the coins without needing the private key).

Its soft-forkable because its a new transaction type.

ps I agree with Greg also that longer-term more scalable solutions are interesting, but I'd like to see the core network work as a stepping stone. As Justus observed: the scalable solutions so far have had non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain 0-confirm.

Adam

On 22 February 2015 at 04:06, Jeff Garzik <jgarzik@bitpay•com> wrote:

> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>>> This isn't some theoretical exercise.  Like it or not many use
>>> insecure 0-conf transactions for rapid payments.  Deploying something
>>> that makes 0-conf transactions unusable would have a wide, negative
>>> impact on present day bitcoin payments, thus "scorched earth"
>
>> And maybe by maintaining first seen policies we're harming the system
>> in the long term by encouraging people to widely deploy systems based
>> on extremely weak assumptions.
>
> Lacking a coded, reviewed alternative, that's only a platitude.
> Widely used 0-conf payments are where we're at today.  Simply ceasing
> the "maintaining [of] first seen policies" alone is simply not a
> realistic option.  The negative impact to today's userbase would be
> huge.
>
> Instant payments need a security upgrade, yes.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote:

FWIW I've been advocating this kind of thing in various forms for literally years, including to hold fidelity bonded banks honest - what you now call 'federated sidechains' - and most recently Feb 12th on #bitcoin-dev:

19:56 < petertodd> leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees 19:57 < petertodd> leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend 19:58 < leakypat> Yeah, proof of double spend would ideally be done at the protocol level 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas...

Implementing it as a general purpose scripting language improvement has a lot of advantages, not least of which is that you no longer need to rely entirely on inherently unreliable P2P networking: Promise to never create two signatures for a specific BIP32 root pubkey and make violating that promise destroy and/or reallocate a fidelity bond whose value is locked until some time into the future. Since the fidelity bond is a separate pool of funds, detection of the double-spend can happen later.

Equally, that *is* what replace-by-fee scorched-earth does without the need for a soft-fork, minus the cryptographic proof and with a bit less flexibility.

> I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.

Is releasing a version of Bitcoin Core with different IsStandard() rules than the previous version vandalism? Is mining with a different policy than other people vandalism? Is mining at a pool that gets sybil attacked vandalism? Are my replace-by-fee tools an act of vandalism? Because every one of those things causes people to get double-spent in the real world, even losing tens of thousands of dollars until they get some sense and stop treating unconfirmed transactions as confirmed.

Is it vandalism if you decide to host a wedding right next to a hairpin corner at a rally race and complain to me that mud is getting on the pretty white dresses? Is it vandalism if I tell that wedding party to fuck off before someone gets hurt? Is it vandalism if some racers take the mudguards off for a few laps to see if we can encourage them to leave before someone gets *actually* hurt? Or someone decides that the solution is to pave the track over and hold a bicycle race instead...

Den 22 feb 2015 13:36 skrev "Peter Todd" <pete@petertodd•org>:

> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specific BIP32 root pubkey and make
> violating that promise destroy and/or reallocate a fidelity bond whose
> value is locked until some time into the future. Since the fidelity bond
> is a separate pool of funds, detection of the double-spend can happen
> later.

Somebody sent me a zero-confirmation transaction, or one that got orphaned after one block. I created a transaction spending that UTXO, and another.

So at that point I have UTXO_orphaned based on the sender's UTXO_origin and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new.

Now he doublespend UTXO_origin to create a UTXO_doublespend (which conflicts with UTXO_orphaned). He conspires with a miner to get it into a block.

Now what? Can my UTXO_old effectively be tainted forever because UTXO_new got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created?

Or otherwise, if only transactions where all UTXO's are currently valid works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves?

In other words, you are unprotected and potentially at greater risk if you create a transaction depending on another zero-confirmation transaction.

On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:

> In other words, you are unprotected and potentially at greater risk if you
> create a transaction depending on another zero-confirmation transaction.

This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money.

I keep telling people not to accept transactions with zero confirmations, but no one listens.

On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock <bip@mattwhitlock•name> wrote:

>On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
>> In other words, you are unprotected and potentially at greater risk
>if you
>> create a transaction depending on another zero-confirmation
>transaction.
>
>This happened to one of the merchants at the Bitcoin 2013 conference in
>San Jose. They sold some T-shirts and accepted zero-confirmation
>transactions. The transactions depended on other unconfirmed
>transactions, which never confirmed, so this merchant never got their
>money.

Great example! Systems that appear more secure than they really are to uninformed users are dangerous. Same reason why brain wallets are such scary technology, and equally, why I like to give a few dollars away every so often to the guys brute forcing weak ones.

>I keep telling people not to accept transactions with zero
>confirmations, but no one listens.

In my experience there's a pattern of "accept unconfirmed; get burned badly/see someone else get burned; stop relying on them" Although of course, there's some bias in that people contact me asking what to do after they get burned. :)

My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help people migrate to that before deprecating the current weaker 0-conf transactions.

If I understand this is also your own motivation.

Feel free to comment on or improve the proposal or find other approaches.

Adam

On 22 February 2015 at 12:34, Peter Todd <pete@petertodd•org> wrote:

> On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote:
>
> FWIW I've been advocating this kind of thing in various forms for
> literally years, including to hold fidelity bonded banks honest - what
> you now call 'federated sidechains' - and most recently Feb 12th on
> #bitcoin-dev:
>
> 19:56 < petertodd> leakypat: now, do note that an advanced version [of replace-by-fee scorched earth] could be to make another tx that alice and bob setup in advance such that if alcie doublespends, bob gets the money *and* alice pays a bunch of cash to miners fees
> 19:57 < petertodd> leakypat: this would work espectially well if we improved the scripting system so a script could evaluate true based on proof-of-doublespend
> 19:58 < leakypat> Yeah, proof of double spend would ideally be done at the protocol level
> 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things that CHECKSIG does into one opcode it'd be really easy, but alas...
>
> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specific BIP32 root pubkey and make
> violating that promise destroy and/or reallocate a fidelity bond whose
> value is locked until some time into the future. Since the fidelity bond
> is a separate pool of funds, detection of the double-spend can happen
> later.
>
> Equally, that *is* what replace-by-fee scorched-earth does without the
> need for a soft-fork, minus the cryptographic proof and with a bit less
> flexibility.
>
>> I agree with Mike & Jeff.  Blowing up 0-confirm transactions is vandalism.
>
> Is releasing a version of Bitcoin Core with different IsStandard() rules
> than the previous version vandalism? Is mining with a different policy
> than other people vandalism? Is mining at a pool that gets sybil
> attacked vandalism? Are my replace-by-fee tools an act of vandalism?
> Because every one of those things causes people to get double-spent in
> the real world, even losing tens of thousands of dollars until they get
> some sense and stop treating unconfirmed transactions as confirmed.
>
> Is it vandalism if you decide to host a wedding right next to a hairpin
> corner at a rally race and complain to me that mud is getting on the
> pretty white dresses? Is it vandalism if I tell that wedding party to
> fuck off before someone gets hurt? Is it vandalism if some racers take
> the mudguards off for a few laps to see if we can encourage them to
> leave before someone gets *actually* hurt? Or someone decides that the
> solution is to pave the track over and hold a bicycle race instead...
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

On Sun, Feb 22, 2015 at 8:11 AM, Adam Back <adam@cypherspace•org> wrote:

> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help people migrate to that before deprecating the
> current weaker 0-conf transactions.

Scenario: Users are using some system in a way that the system was not intended to be used. Let me also further constrain the scenario and suggest that the function (pretend that means instantaneous confirmed transactions) that the user wants is impossible. So in this scenario, is it your job as some developer to change the system to do something it wasn't designed to do? I mean, you certainly weren't the one telling them they should accept zero confirmation transactions. Also, I make no claims as to whether this scenario maps accurately to the current topic.

- Bryan http://heybryan.org/ 1 512 203 0507

On Sun, Feb 22, 2015 at 02:11:31PM +0000, Adam Back wrote:

> My actual point outside of the emotive stuff (and I should've stayed
> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help people migrate to that before deprecating the
> current weaker 0-conf transactions.
>
> If I understand this is also your own motivation.

Indeed, which is why I wrote some easy-to-use and highly effective tools to pull off double-spends and made sure to publicise them and their effectiveness widely. They've had their desired effect and very few people are relying on unconfirmed transactions anymore. As for the remaining, next week alone I'll be volunteering one or two hours of my consulting time to discuss solutions with a team doing person-to-person trading for instance.

Like I've said repeatedly, the current "weaker" 0-conf transactions gets people new to Bitcoin - both individuals and companies - burnt over and over again because inevitably someone eventually gets motivated and breaks them, and suddenly they lose stacks of money.

Keeping *that* kind of "security" around rather than depreciating it ASAP and being honest about what Bitcoin can do does no-one any good.

Anyway, there is no one magic solution to this stuff - the best solutions vary greatly on the situation.

Den 22 feb 2015 14:29 skrev "Natanael" <natanael.l@gmail•com>:

>
>
> Den 22 feb 2015 13:36 skrev "Peter Todd" <pete@petertodd•org>:
>
> > Implementing it as a general purpose scripting language improvement has
> > a lot of advantages, not least of which is that you no longer need to
> > rely entirely on inherently unreliable P2P networking: Promise to never
> > create two signatures for a specific BIP32 root pubkey and make
> > violating that promise destroy and/or reallocate a fidelity bond whose
> > value is locked until some time into the future. Since the fidelity bond
> > is a separate pool of funds, detection of the double-spend can happen
> > later.
>
> Somebody sent me a zero-confirmation transaction, or one that got

orphaned after one block. I created a transaction spending that UTXO, and another.

>
> So at that point I have UTXO_orphaned based on the sender's UTXO_origin

and my UTXO_old (because I've had it unspent for a long time), both in one transaction, creating UTXO_new.

>
> Now he doublespend UTXO_origin to create a UTXO_doublespend (which

conflicts with UTXO_orphaned). He conspires with a miner to get it into a block.

>
> Now what? Can my UTXO_old effectively be tainted forever because UTXO_new

got invalidated together with UTXO_orphaned? Will that transaction be a valid proof of doublespend against a new UTXO_replacement I created?

>
> Or otherwise, if only transactions where all UTXO's are currently valid

works as doublespend proofs, aren't you still just left without protection against any one miner that conspires with doublespend attempting thieves?

>
> In other words, you are unprotected and potentially at greater risk if

you create a transaction depending on another zero-confirmation transaction.

Additional comments:

If you punish the creation of UTXO_replacement, you will punish people who was lead to think zero-confirmation transactions were safe and thus that chains of zero-confirmation transactions also were safe.

If you don't, but STILL accept chains of zero-confirmation transactions were not all of them are covered by fidelity bonds, then you failed to protect yourself against thieves who creates chains of unconfirmed transactions.

Another question: if all transactions in the chain are covered by fidelity bonds for their own value, which one pays out to who? Does only the first one pay out, and only to the last party in the chain? Or to every subsequent party after him? In full or just a fraction? Why, why not? You might not know which of these serviced their customers in full without getting full value back in exchange due to the doublespend.

What if the fidelity bond is too small, do you stop accepting it as a zero-confirmation transaction?

Do you even accept chains of unconfirmed transactions at all?

On 2015-02-22 14:33, Peter Todd wrote:

> On Sun, Feb 22, 2015 at 02:11:31PM +0000, Adam Back wrote:
>> My actual point outside of the emotive stuff (and I should've stayed
>> away from that too) is how about we explore ways to improve practical
>> security of fast confirmation transactions, and if we find something
>> better, then we can help people migrate to that before deprecating the
>> current weaker 0-conf transactions.
>>
>> If I understand this is also your own motivation.
>
> Indeed, which is why I wrote some easy-to-use and highly effective
> tools
> to pull off double-spends and made sure to publicise them and their
> effectiveness widely. They've had their desired effect and very few
> people are relying on unconfirmed transactions anymore.

You mean you wrote a bunch of FUD about zeroconf transactions while working for companies like Coinbase and GreenAddress that were trying to sell 100% centralized solutions? Lets just be clear on this.

I and many other people tried your replace-by-fee tools and found out that they worked **maybe** 1-2% of the time. You claimed 95% success rates.

> As for the
> remaining, next week alone I'll be volunteering one or two hours of my
> consulting time to discuss solutions with a team doing person-to-person
> trading for instance.

A "team"

You mean a **Company**? We don't need yet another 100% centralized LocalBitcoins snooping on our transactions.

On Sun, Feb 22, 2015 at 03:18:05PM +0000, joliver@airmail•cc wrote:

> > Indeed, which is why I wrote some easy-to-use and highly effective
> > tools
> > to pull off double-spends and made sure to publicise them and their
> > effectiveness widely. They've had their desired effect and very few
> > people are relying on unconfirmed transactions anymore.
>
> You mean you wrote a bunch of FUD about zeroconf transactions while
> working for companies like Coinbase and GreenAddress that were trying to
> sell 100% centralized solutions? Lets just be clear on this.

You lot spend so much time trying to claim I'm working for people I'm not that I have a bad feeling I'm going to end up having to explain what an internet troll is to "friendly" Revenue Canada tax auditor...

> I and many other people tried your replace-by-fee tools and found out
> that they worked **maybe** 1-2% of the time. You claimed 95% success
> rates.

That tool was intentionally shipped with unclear instructions and nearly all the double-spend strategies turned off by default; you can easily increase that number with a little understanding.

> > As for the
> > remaining, next week alone I'll be volunteering one or two hours of my
> > consulting time to discuss solutions with a team doing person-to-person
> > trading for instance.
>
> A "team"
>
> You mean a **Company**? We don't need yet another 100% centralized
> LocalBitcoins snooping on our transactions.

"[Bitcoin-development] Eliminating double-spends with two-party self-escrow for high value transactions", Peter Todd, Apt 26th 2014, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05166.html

(note that the above should be updated to use CHECKLOCKTIMEVERIFY)

On 02/22/2015 07:50 AM, Matt Whitlock wrote:

> This happened to one of the merchants at the Bitcoin 2013
> conference in San Jose. They sold some T-shirts and accepted
> zero-confirmation transactions. The transactions depended on other
> unconfirmed transactions, which never confirmed, so this merchant
> never got their money.
>
> I keep telling people not to accept transactions with zero
> confirmations, but no one listens.

A better solution is to track the failure rate of zero confirmation transactions, and adjust prices accordingly to cover the expected loss.

This is what every merchant *already does* since no payment method has a 0% fraud rate.

Even physical cash has a probability of being counterfeit, and the prices you pay for things at a convenience store already have that risk priced in.

The idea that zero confirmation transactions require a 100% guarantee is a strawman, especially since there exists no number of confirmations the actually produce a 100% irreversibility guarantee.

Zero confirmation transactions can work as long as the risk of reversal is measurable and reasonably stable.

Den 22 feb 2015 17:00 skrev "Justus Ranvier" <justusranvier@riseup•net>:

>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> > This happened to one of the merchants at the Bitcoin 2013
> > conference in San Jose. They sold some T-shirts and accepted
> > zero-confirmation transactions. The transactions depended on other
> > unconfirmed transactions, which never confirmed, so this merchant
> > never got their money.
> >
> > I keep telling people not to accept transactions with zero
> > confirmations, but no one listens.
>
> A better solution is to track the failure rate of zero confirmation
> transactions, and adjust prices accordingly to cover the expected loss.
>
> This is what every merchant *already does* since no payment method has
> a 0% fraud rate.
>
> Even physical cash has a probability of being counterfeit, and the
> prices you pay for things at a convenience store already have that
> risk priced in.
>
> The idea that zero confirmation transactions require a 100% guarantee
> is a strawman, especially since there exists no number of
> confirmations the actually produce a 100% irreversibility guarantee.

The problem with this approach is that it is worthless as a predictor. We aren't dealing with traffic safety and road design - we are dealing with adaptive attackers and malicious miners and pools.

Anything which does not invalidate blocks carrying doublespends WILL allow malicious miners and pools to conspire with thieves to steal money. The probability of being hit will then be (their proliferation in your business area) * (their fraction of the mining power).

That might seem to give small numbers for most sets of reasonable assumptions. But the problem is that's only an average, and the people being hit might have small profit margins - one successful attack can place hundreds of merchants in red numbers and force them to shut down.

You should never expose yourself to attacks which you can't defend against and which can be fatal. In particular not if there's nothing in the environment that is capable of limiting the size or numbers of any attacks. And there's no such thing today in Bitcoin.

This is why I sketched out the multisignature notary approach, and why some decided to extend that approach with collateral (NoRiskWallet) to further reduce trust in the notary. This is the single most practical approach I know of today to achieve ACTUAL SECURITY for unconfirmed transactions.

Don't like it? See if you can do better!

Just don't rely on zero-confirmation transactions!

On 02/22/2015 10:17 AM, Natanael wrote:

> The problem with this approach is that it is worthless as a
> predictor. We aren't dealing with traffic safety and road design -
> we are dealing with adaptive attackers and malicious miners and
> pools.
>
> Anything which does not invalidate blocks carrying doublespends
> WILL allow malicious miners and pools to conspire with thieves to
> steal money. The probability of being hit will then be (their
> proliferation in your business area) * (their fraction of the
> mining power).
>
> That might seem to give small numbers for most sets of reasonable
> assumptions. But the problem is that's only an average, and the
> people being hit might have small profit margins - one successful
> attack can place hundreds of merchants in red numbers and force
> them to shut down.
>
> You should never expose yourself to attacks which you can't defend
> against and which can be fatal. In particular not if there's
> nothing in the environment that is capable of limiting the size or
> numbers of any attacks. And there's no such thing today in
> Bitcoin.
>
> This is why I sketched out the multisignature notary approach, and
> why some decided to extend that approach with collateral
> (NoRiskWallet) to further reduce trust in the notary. This is the
> single most practical approach I know of today to achieve ACTUAL
> SECURITY for unconfirmed transactions.
>
> Don't like it? See if you can do better!
>
> Just don't rely on zero-confirmation transactions!

You just disproved your own argument.

It is possible to predict risk, and therefore to price the risk.

You also noted that for some Bitcoin users, the price of that risk is too high for the types of transactions in which wish to engage.

In what way does that translated into a universal requirement for everybody to use multisignature notaries?

Surely the users who can afford the risk can use zero conf if they like, and those who can't can use multisig notaries?

- Sent from my tablet Den 22 feb 2015 17:25 skrev "Justus Ranvier" <justusranvier@riseup•net>:

>
> You just disproved your own argument.
>
> It is possible to predict risk, and therefore to price the risk.

Your fault is that you assume the predictions can be reliable and trustable.

They can not be.

The data you have available has none of the indicators you actually NEED to make predictions. You're making extrapolations from the past, not calculations based on recent trends and behavior globally.

> You also noted that for some Bitcoin users, the price of that risk is
> too high for the types of transactions in which wish to engage.
>
> In what way does that translated into a universal requirement for
> everybody to use multisignature notaries?

It isn't universal. It is just the most practical solution if you need instant confirmation for high value transactions with customers you don't yet trust.

> Surely the users who can afford the risk can use zero conf if they
> like, and those who can't can use multisig notaries?

Use whatever you want. I don't care. I will warn you about the risks and make suggestions, but I won't force you to do anything differently.

>
> This happened to one of the merchants at the Bitcoin 2013 conference in
> San Jose. They sold some T-shirts and accepted zero-confirmation
> transactions. The transactions depended on other unconfirmed transactions,
> which never confirmed, so this merchant never got their money.
>

Beyond the fact that this risk can be priced in when enough data is available, I'd be interested to talk to this merchant and dig into what happened a bit.

For example:

   1. Was the dependent tx non-standard?
   2. Was it double spent?
   3. Could a wallet have co-operated with the P2P network to detect and
   flag whatever the issue was?

My own experience has been that when this happens, it's usually not the result of outright maliciousness (especially not at a Bitcoin t-shirt seller at a Bitcoin conference!) but rather something messed up somewhere and the software in use just didn't detect it well enough.