Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.41 as permitted sender)
	client-ip=209.85.192.41; envelope-from=adam.back@gmail.com;
	helo=mail-qg0-f41.google.com; 
MIME-Version: 1.0
Sender: adam.back@gmail.com
In-Reply-To: <20150222123428.GA6570@savin.petertodd.org>
References: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
	<20150222123428.GA6570@savin.petertodd.org>
Date: Sun, 22 Feb 2015 14:11:31 +0000
Message-ID: <CALqxMTHuD1WuV_mVeSD-TaFszVms=hogUTL2bNc7YgNDyhVOoQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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)
Precedence: list

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 re=
place-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 impro=
ved 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 th=
e protocol level
> 19:59 < petertodd> leakypat: if satoshi hadn't make the multiple things t=
hat 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 vandalis=
m.
>
> 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