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
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 39906305
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 13:12:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96E8CFB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 13:12:54 +0000 (UTC)
Received: from mail-qg0-f46.google.com ([209.85.192.46]) by mrelay.perfora.net
(mreueus003) with ESMTPSA (Nemesis) id 0MKKIa-1ZATJ521w6-001f9Y for
<bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 15:12:53 +0200
Received: by qgii30 with SMTP id i30so3464200qgi.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 Jun 2015 06:12:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.27.70 with SMTP id b67mr43010609qkb.86.1435669972796;
Tue, 30 Jun 2015 06:12:52 -0700 (PDT)
Received: by 10.96.28.39 with HTTP; Tue, 30 Jun 2015 06:12:52 -0700 (PDT)
In-Reply-To: <20150630013736.GA11508@savin.petertodd.org>
References: <20150629050726.GA502@savin.petertodd.org>
<5591E10F.9000008@thinlink.com>
<20150630013736.GA11508@savin.petertodd.org>
Date: Tue, 30 Jun 2015 15:12:52 +0200
Message-ID: <CALqxMTH_5rtOs=aSNiVrfsG_sqQDCnTr-8qBH3Qji+8g_dAMcQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:RWlgehahXpK3FxZk/GW+bmj4Ql2Gr3LMgEBILeCcf84QUljUx06
I9d/wQVpFhc3hca7kzLsILUSddfPOlA9S7L5+5iNHxu6hsdgyBWx7nnvXAccUvOQjQQK3E3
H0Lq4fsnUi5z2gPXLpeoywk+X8X3wGiZwTTeYTSoAAvyfLtaPkjloC2zA6drGkDF7Mcj+gH
FLVbHVjysd3mEm83Cllzg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dAaURWaVlvA=:Gqid7DfsMql0ARYg49E5d5
+ZXWQ52uehROtFi4XRLnD3rJAXf20M6k3SygesARsnUPL6ZIR4dOgxTjiWsjUDIrmjhhLLY5u
oYbabKrx6rzKd5s5EkSq6hz67jb0V8JG3m1Bbdo5BUxjK6G1FZq8mPzKAmbZLAMDTQUnRxapw
kcxIRkbxRjzlkGtE8dmQgHWUri2QkV0fJ52tfoA+L7urEucaGaZfmQuPK31VN06H6FTdmu4He
6nYHUR17VMY0jXDTzqYPsxh+kzRhktiZft/CDp4m8rtZTYnTtv2yzttCkyffMrrhYjJ0GSBZR
TeD0nZCmn4bRXiaf5O6ayNPEcgl4K3k4nMragK5iuBM4h75vjIOQepM+oXeG9pDSfM0S2GRc8
yACQpnLPPYsxSluvu4xEb+dfVOgJzS4Edy31U4ha3GvuNVsSOGpCsvZqGdHj7xuIx2IWW1VO6
gohLptbt8L79I5yZADKazPnparljmQIe2Iy2j5LROVQH6cYf7vSd/QxL4Xb1fRPgYif85KqRO
Nxg9oypPs5BDxEvj7T2PuKnQppXYMtNhi6vIoQpIOBBeWzAITpJ3uhHrgtpPMelzEMF/BXxri
LF2NozMLX+P5UL9icz8EbuaknOe6SjcZDsSNAWiKclOvhH2wPC7QvWs3tX09tHLl7/b5/tc3D
VPqVzMfstv6gFOq2YeGwxQm2qyPX/wxFeKGO6uu2d1qU5nw==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
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: Tue, 30 Jun 2015 13:12:55 -0000
It is correct to view first-seen miner and relay policy as
honour-based, though it is the current default.
I think it would be better to deploy full-RBF in an opt-in way and
leave the current default miner & relay policies as is. So for
example a new signature flag or transaction type that is marked as
opting-in waiving the first-seen policy.
In this way we can get a smoother transition for people away from the
first-seen assumption, towards greenaddress (trust based) and
lightning / payment channel solutions. Mid-term the channel and hub
model can provide fast secure 0-confirm transactions, which are
generically not known to be directly and robustly securable via miner
consensus.
As we've seen abruptly stopping the first-seen miner & relay policy is
risky and unpopular and causes people to seek contracts with miners to
retain first-seen. This is itself a bad trend for fungibility for
obvious reasons.
We shouldn't prejudge people's and segment's of business weak-reliance
on first-seen. Some types of payments are generally high trust (known
relationships) or physical stores or very low marginal cost (coffee
marginal cost <10c, sale price > $2 or lower ebook, audio stream etc
as embodied by fremium model). It is not ours to prejudge and kill
their business. It our job to help improve network security however,
so that they do not have to eat a fraud cost. And that is do able
with trust via greenaddress, or without trust (other than
time-preference) via the hub & channel model.
Security maybe incrementally improvable via non-spendable relaying of
proof of double-spent status, and services that try to measure % of
miners by hashrate with assumption of first-seen that have have seen a
given transaction first, though I am not sure such approaches are
robust enough to invest time in vs greenaddress or hub & channel.
Any thoughts on the simplest way to support an opt-in version of full-RBF?
Adam
On 30 June 2015 at 03:37, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
>> On 6/28/2015 10:07 PM, Peter Todd wrote:
>> >Worryingly large payment providers have shown
>> >willingness(4) to consider extreme measures such as entering into legal
>> >contracts directly with large miners to ensure their transactions get mined.
>> >This is a significant centralization risk and it is not practical or even
>> >possible for small miners to enter into these contracts, leading to a situation
>> >where moving your hashing power to a larger pool will result in higher profits
>> >from hashing power contracts; if these payment providers secure a majority of
>> >hashing power with these contracts inevitably there will be a temptation to
>> >kick non-compliant miners off the network entirely with a 51% attack.
>> >
>>
>> Your incomprehensible meddling with successful usage patterns
>> threatens to have unintended consequences directly in opposition to
>> your own stated goal of decentralization. And yet you persist.
>>
>> As we deliberately break things and turn the P2P network into a
>> completely unpredictable hodge-podge of relay policies, we should
>> expect many more participants to bypass the P2P network entirely.
>>
>> Many of the pieces are already in place.
>>
>> If we wanted the P2P network to have more predicable behavior, it
>> would be possible for nodes to provide incentives to their
>> neighbors. For example, if you had a pair of nodes, you could test
>> your peers to see that they actually do relay "standard"
>> transactions. This would have emergent usability benefits for the
>> P2P network as a whole.
>
> To be clear, full-RBF is a change that broadens what the P2P network
> relays - transactions previously not relayed are now relayed. Under no
> circumstance will full-RBF result in transactions *not* being relayed
> that previously were relayed. This makes the P2P network more useful
> rather than less, as it gives a predictable and uniform method to get
> transactions to a wider variety of miners with a wider variety of
> policies.
>
> Note how even if no miners ever supported full-RBF, supporting full-RBF
> on relay nodes would still be useful to users as it provides an easy and
> cost-effective mechanism to rebroadcast transactions. In fact,
> supporting full-RBF by default and disabling it if getblocktemplate is
> called would be reasonable, if more than a bit of a hack!
>
> In any case, my pull-req lets you set -fullrbfactivationtime=0 as a
> simple and easy way to disable full-RBF functionality. Miners and relay
> nodes who choose not to support it can easily do so, similar to how
> OP_RETURN transactions can be disabled with -datacarrier=0
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
