From: Adam Back <adam@cypherspace•org>
To: Peter Todd <pete@petertodd•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 14:11:31 +0000 [thread overview]
Message-ID: <CALqxMTHuD1WuV_mVeSD-TaFszVms=hogUTL2bNc7YgNDyhVOoQ@mail.gmail.com> (raw)
In-Reply-To: <20150222123428.GA6570@savin.petertodd.org>
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
next prev parent reply other threads:[~2015-02-22 14:11 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 [this message]
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='CALqxMTHuD1WuV_mVeSD-TaFszVms=hogUTL2bNc7YgNDyhVOoQ@mail.gmail.com' \
--to=adam@cypherspace$(echo .)org \
--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