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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1YPXFy-0007cU-WD
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 14:11:39 +0000
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;
Received: from mail-qg0-f41.google.com ([209.85.192.41])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPXFw-0004JJ-Tb
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 14:11:38 +0000
Received: by mail-qg0-f41.google.com with SMTP id i50so20887873qgf.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Feb 2015 06:11:31 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.229.25.200 with SMTP id a8mr15426198qcc.22.1424614291471;
Sun, 22 Feb 2015 06:11:31 -0800 (PST)
Sender: adam.back@gmail.com
Received: by 10.96.56.136 with HTTP; Sun, 22 Feb 2015 06:11:31 -0800 (PST)
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
X-Google-Sender-Auth: 7AunybWXiLaIjHcZfGZ24F6_hVM
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
X-Spam-Score: -1.4 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YPXFw-0004JJ-Tb
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 14:11:39 -0000
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
|
