1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YPVkM-0005Ry-Jt
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 12:34:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.43 as permitted sender)
client-ip=62.13.149.43; envelope-from=pete@petertodd.org;
helo=outmail149043.authsmtp.co.uk;
Received: from outmail149043.authsmtp.co.uk ([62.13.149.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YPVkL-0001TJ-AA for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 12:34:54 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MCYcSO069365;
Sun, 22 Feb 2015 12:34:38 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MCYYNI061100
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 22 Feb 2015 12:34:36 GMT
Date: Sun, 22 Feb 2015 07:34:28 -0500
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20150222123428.GA6570@savin.petertodd.org>
References: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5"
Content-Disposition: inline
In-Reply-To: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 29e54bd9-ba8f-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAAUHlAWAgsB AmMbWlZeU1l7WmQ7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRR18 dXd3LGBycQRHeH4+ ZEFqXngVXk0vcEIv
FkdJRzwOM3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDFzog SgoEFCkiVVUfQD00
NBUiYlkEAAMQNA03 MF0sQxoEOhwfEW8W E0ZQCitUYkIZSiwn
RUNgUBxWCjBFRS5X D1giM1pGDzEaRHIe XRMDEwsEV2It
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YPVkL-0001TJ-AA
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)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2015 12:34:54 -0000
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 repl=
ace-by-fee scorched earth] could be to make another tx that alice and bob s=
etup in advance such that if alcie doublespends, bob gets the money *and* a=
lice pays a bunch of cash to miners fees
19:57 < petertodd> leakypat: this would work espectially well if we improve=
d the scripting system so a script could evaluate true based on proof-of-do=
ublespend
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 tha=
t 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...
--=20
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8
--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJU6czPXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxN2MyZjM0NmY4MWU5Mzk1NmM1Mzg1MzE2ODJmNWFmM2E5
NWY5Yzk0Y2I3YTg0ZTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftqRwf/Zj9DMFWWx4csiONsp3Zahf0N
t2TwRYDC1oYcqRoFucTPBPoBZLU6Eo9Z5ZcVpW08m2JeC6Qe3S+PyJeHQGHpIZYJ
ZPjbqCe6nvBxkf2ZLpLIrNw5cqkEYnrR0KecZgK6dKCLECT35EZnF5yCGmOpjM6F
cispcjpsmunrXKpfuPAN7isFK64ZoKVANep80prI4H3Bx15DQSpCH+jNCMvrFh7a
SQQjM9Ph+SJF1XV5ijbTXUIO8H7y3hGqPa9jNPb7epK7uDaXz5fwVs1x8+hRQwGt
2eqie3aNNE1RcHSKSHmuolCFicPJ9VfL7Qe2L3wpf2qanpfllEwlw1amY2FXWw==
=7BwV
-----END PGP SIGNATURE-----
--FL5UXtIhxfXey3p5--
|
