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 07:34:28 -0500 [thread overview]
Message-ID: <20150222123428.GA6570@savin.petertodd.org> (raw)
In-Reply-To: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-02-22 12: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 [this message]
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
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=20150222123428.GA6570@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