From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Date: Sun, 22 Feb 2015 09:33:53 -0500 [thread overview]
Message-ID: <20150222143353.GA32621@savin.petertodd.org> (raw)
In-Reply-To: <CALqxMTHuD1WuV_mVeSD-TaFszVms=hogUTL2bNc7YgNDyhVOoQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
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.
--
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-02-22 14:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 8:02 Adam Back
2015-02-22 12:34 ` Peter Todd
2015-02-22 13:29 ` Natanael
2015-02-22 13:50 ` Matt Whitlock
2015-02-22 14:07 ` Peter Todd
2015-02-22 16:00 ` Justus Ranvier
2015-02-22 16:17 ` Natanael
2015-02-22 16:25 ` Justus Ranvier
2015-02-22 16:36 ` Natanael
2015-02-23 11:03 ` Mike Hearn
2015-02-22 14:44 ` Natanael
2015-02-22 14:11 ` Adam Back
2015-02-22 14:25 ` Bryan Bishop
2015-02-22 14:33 ` Peter Todd [this message]
2015-02-22 15:18 ` joliver
2015-02-22 15:41 ` Peter Todd
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=20150222143353.GA32621@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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