From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Tue, 7 May 2013 11:00:52 +0200 [thread overview]
Message-ID: <CANEZrP2TTcBJX86T+aRULDb7h9=MmoQa5U4cW0Z5ka8QAe_6Jg@mail.gmail.com> (raw)
In-Reply-To: <20130506171943.GA22505@petertodd.org>
> You mean scam you with a zero-conf transaction that hasn't actually been
> broadcast?
Yeah. Or just scam you at all. It's hard to imagine an organisation as
a big as a mobile carrier engaging in financial scamming (roaming fees
excepted).
I've said this before, but I think it's worth repeating. The
double-spend protection the block chain gives you has a sweet spot
where it's really, really valuable (essential even) and then there are
lots of kinds of transactions on either side of that sweet spot that
don't really benefit from it.
Obvious/trivial case where you don't need a block chain - Facebook
buys Instagram for a gajillion coins. The legal system is plenty good
enough to ensure the payments are honoured. Another example, when my
employer pays me my salary. They aren't going to double spend this
except through some horrible accident that we can get sorted out some
other way.
Another case, very small payments. This is Satoshi's bag of crisps
example. If the cost/complexity of double spending is higher than what
the payment is worth, again, you don't really need the block chain.
That's why it's worth optimising unconfirmed transactions to be harder
to double spend, it optimises (pushes up) that lower bar.
Place where you really want the chain - largeish sums of money are
moving around, but not large enough to justify expensive
cross-jurisdictional legal action, or where the cost of identity
verification and all the associated paperwork is just too high. I
guess most online transactions fall into this bucket today.
next prev parent reply other threads:[~2013-05-07 9:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn [this message]
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP2TTcBJX86T+aRULDb7h9=MmoQa5U4cW0Z5ka8QAe_6Jg@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox