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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F02FBCC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jul 2015 13:13:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
[209.85.220.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6DF6C1C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jul 2015 13:13:36 +0000 (UTC)
Received: by qkbp125 with SMTP id p125so51125934qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 02 Jul 2015 06:13:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=09Oc1+6Ocq+rNo4j8k9is9alhPY7Nk8mKhS333Cyx/w=;
b=DIsEEHiTNrbjiIokg3lnlm6EFDpZdM7/hGSU8/KWmD2kTAOQPb+twYSeSTHeT7s0XG
qEyPrBWlaL7zv7jWV8wvgNT/Ca14kVdTihEdDC95ZxXeeK2rgyiMuA2oImwtEiMg7JJf
npND7O8/gPKLhQePqUAA3zFZovXgsLeFytNlDKR7JRgLuL4ICdA/cs1wSlhuXDEsWXqZ
v0A/1yWP0BMTXFH4FZPIrV7u0j5x76l25s2Nq1rdlc+d9peOJ8jPeWss/MyGI1/KRl2X
dktVU4+azhh6KgiLqfDwm7888+j+nWzOKCmrbwhcAAAhVeSJ+fCIT/DOE/1Cl+0GAVHm
PfZg==
MIME-Version: 1.0
X-Received: by 10.140.237.147 with SMTP id i141mr44853819qhc.25.1435842815542;
Thu, 02 Jul 2015 06:13:35 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 2 Jul 2015 06:13:35 -0700 (PDT)
In-Reply-To: <1854821.ToCRAf8eXU@crushinator>
References: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
<CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com>
<1854821.ToCRAf8eXU@crushinator>
Date: Thu, 2 Jul 2015 14:13:35 +0100
Message-ID: <CAE-z3OUqxjnRjWPtSzbSFoxPNGoPQyQ8G=e-yegm9JAZ+SzyBw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135ad28f94af50519e43460
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed
transactions with a bounty.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2015 13:13:37 -0000
--001a1135ad28f94af50519e43460
Content-Type: text/plain; charset=UTF-8
I wonder if that would be a viable way for payment services to pay to
protect against double spending.
If the payment processor was handling 1000 BTC every block and was willing
to pay 0.1% fees, then it could create a transaction with 1BTC in fees.
If an attacker tried to double spend a transaction of 0.1BTC, then even if
he was to spend the entire transaction to fees, the payment processor would
be able to out bid him.
It kind of works like insurance. The payment processor combines lots of
small double spend threats and protects them with a single transaction.
The processor could keep sending out a larger and large transaction (with
fee) until eventually a block is found.
It requires RBF. First seen safe would be incompatible, if the double
spender gets their transaction into the system first.
A 1BTC fee transaction in nearly every block would also be a boost for
network security.
It avoids Peter Todd's complaint that mining pools might make secret deals
with payment services. The transaction would be public and all miners
could include it in their block.
On Thu, Jul 2, 2015 at 5:57 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.
>
>
> On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:
> > This is called child pays for parent and there is a three year old pull
> > request implementing it:
> >
> > https://github.com/bitcoin/bitcoin/pull/1647
> >
> > The points regarding sweep transaction UI is out of scope for a BIP I'm
> > afraid. I suggest talking with wallet authors, and if agreement can be
> > found writing a pull request.
> > On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail.com> wrote:
> >
> > > This is a process BIP request to add functionality to the Bitcoin-Core
> > > reference implementation. If accepted, this could also add
> > > flexibility into any future fee schedules.
> > >
> > > https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1135ad28f94af50519e43460
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I wonder if that would be a viable way for payme=
nt services to pay to protect against double spending.<br><br></div>If the =
payment processor was handling 1000 BTC every block and was willing to pay =
0.1% fees, then it could create a transaction with 1BTC in fees.=C2=A0 <br>=
<br></div><div>If an attacker tried to double spend a transaction of 0.1BTC=
, then even if he was to spend the entire transaction to fees, the payment =
processor would be able to out bid him.<br><br></div><div>It kind of works =
like insurance.=C2=A0 The payment processor combines lots of small double s=
pend threats and protects them with a single transaction.<br><br></div><div=
>The processor could keep sending out a larger and large transaction (with =
fee) until eventually a block is found.<br><br></div><div>It requires RBF.=
=C2=A0 First seen safe would be incompatible, if the double spender gets th=
eir transaction into the system first.<br><br></div><div>A 1BTC fee transac=
tion in nearly every block would also be a boost for network security.<br><=
br></div><div>It avoids Peter Todd's complaint that mining pools might =
make secret deals with payment services.=C2=A0 The transaction would be pub=
lic and all miners could include it in their block.<br></div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 2, 2015 at 5:=
57 AM, Matt Whitlock <span dir=3D"ltr"><<a href=3D"mailto:bip@mattwhitlo=
ck.name" target=3D"_blank">bip@mattwhitlock.name</a>></span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">PR#1647 only addresses miner policy, though, =
right? I believe the BIP is addressing the user-facing side of this functio=
nality. CPFP mining policy does very little good if wallets don't offer=
any way for users to goose up incoming transactions.<br>
<span class=3D"im HOEnZb"><br>
<br>
On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:<br>
> This is called child pays for parent and there is a three year old pul=
l<br>
> request implementing it:<br>
><br>
> <a href=3D"https://github.com/bitcoin/bitcoin/pull/1647" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/1647</a><br=
>
><br>
> The points regarding sweep transaction UI is out of scope for a BIP I&=
#39;m<br>
> afraid. I suggest talking with wallet authors, and if agreement can be=
<br>
> found writing a pull request.<br>
> On Jul 1, 2015 9:44 PM, "Dan Bryant" <<a href=3D"mailto:d=
kbryant@gmail.com">dkbryant@gmail.com</a>> wrote:<br>
><br>
> > This is a process BIP request to add functionality to the Bitcoin=
-Core<br>
> > reference implementation.=C2=A0 If accepted, this could also add<=
br>
> > flexibility into any future fee schedules.<br>
> ><br>
> > <a href=3D"https://github.com/d4n13/bips/blob/master/bip-00nn.med=
iawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/d4n13/bips/=
blob/master/bip-00nn.mediawiki</a><br>
</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________=
___________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
--001a1135ad28f94af50519e43460--
|
