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
|
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 <jgarzik@exmulti.com>) id 1SIjYw-0001lM-Gb
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Apr 2012 16:41:30 +0000
X-ACL-Warn:
Received: from mail-vb0-f47.google.com ([209.85.212.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SIjYr-000430-1N
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Apr 2012 16:41:30 +0000
Received: by vbbfr13 with SMTP id fr13so3397481vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 13 Apr 2012 09:41:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=wmYre3CpmH4MC0NgVt5O/91o8kibl5UirpsswIYt0Y4=;
b=ED61AJLfxUm3ntY0RLtgMxOS2EKqL/IjJDdmZrjDwF+0TDfzsxCg6R+o9qWtYs8uoC
q4sNZ4PJc8+RoOOlUL8qlu+elbaKOfeTmY8XbjCQH/bggwAQK9uiUCuQA5hY+rK0bEem
rsYyBOPQ6f4fzpS6za1a8z1ZdwCX4nCt1Ewf2mZnIf4XJ2RMLG2dSWK8bN3H7xJ5yIig
6L23G6DTrrGhavfb6YQozTr41/yfwk8kX5F6Nexrhlp5ePnaBj0QvSv8IY31SIdoB7EO
c5J5cBwQhGwD/KrRRSK3v9dV8v8CuCCt3dBb3/KOq05ZGdxRR7YKszJCnAtRoX9+DbrK
sxCg==
MIME-Version: 1.0
Received: by 10.220.141.84 with SMTP id l20mr1103979vcu.31.1334335279473; Fri,
13 Apr 2012 09:41:19 -0700 (PDT)
Received: by 10.52.109.33 with HTTP; Fri, 13 Apr 2012 09:41:19 -0700 (PDT)
X-Originating-IP: [99.43.178.25]
In-Reply-To: <CANEZrP28Wf6RVOgd85COkE-vLdtCbyQYa0b9QvPFt9W1DzNJag@mail.gmail.com>
References: <CA+8xBpc5CZ9Sx4MwPdeS0-5frnV9B+mJ5OwcPoUVrygTawiJBg@mail.gmail.com>
<CANEZrP28Wf6RVOgd85COkE-vLdtCbyQYa0b9QvPFt9W1DzNJag@mail.gmail.com>
Date: Fri, 13 Apr 2012 12:41:19 -0400
Message-ID: <CA+8xBpcNd-s9S-zDGO6gGwnd1sFSUikH1fAnCUoG1WiL5kkmVg@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnI52QMKk8eaEzAgL5nr2kiOHmTEB3gBobheAq5CbJOxAXau68wKkvTQAzzN5QH0LXGBmlm
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1SIjYr-000430-1N
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic
behavior
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: Fri, 13 Apr 2012 16:41:30 -0000
On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn <mike@plan99.net> wrote:
> It sounds OK as long as you exclude nLockTimed transactions.
ACK, agreed
> That said, if you broadcast a transaction that does not meet the fee
> rules, you should be able to notice that it wasn't accepted by your
> peers immediately. Today it's painful because the protocol isn't very
> chatty - in bitcoinj I plan to do this by announcing to half the
> connected peers and waiting to see if the transaction comes back on
> the other half. Getting a response from a peer that the TX was dropped
> for reasons {x,y,z} is a better design but needs another protocol
> change.
>
> So having transactions expire would address the case where somebody
> broadcasts a transaction that successfully propagates across the
> network, but then isn't actually accepted by miners for some reason.
Correct. As mentioned, this change should impact few TXs on the
existing network.
It's mostly about getting everyone to collectively agree that
transactions should expire, if they don't make it into a block.
(excl. nLockTime stuff) A minor technical step, but also a useful
policy step.
> For instance due to a change in the default fee schedules. That risk
> can be mitigated somewhat by being careful about such changes (timed
> phase ins set multiple months out so people have time to upgrade,
> alerts announcing it, etc).
>
> I'm not sure we should be encouraging users to attach fees to
> transactions though. Even if you can replace a transaction after a
> couple of days, the user experience of trying to get the fee "right"
> is atrocious.
Yes -- I think there is near-universal agreement on this user experience point.
> I don't think any sensible merchant will actually be
> willing to put their customers through this nonsense. If somebody
> broadcasts a transaction that successfully propagates across a big
> chunk of the network but then gets stuck due to lacking sufficient
> fees, the best fix is for the merchant to broadcast another
> transaction that spends the first and increases the fees on it that
> way. After this happens a few times, if I was a merchant I'd be
> tempted to just ask buyers to submit the TX to me directly and I'll
> handle keeping up with what miners currently charge and attaching
> fees. I don't want my customers to have to think about this and have
> trades spuriously fail when they forget.
>
> That design requires a minor change to how fees are calculated inside
> the memory pool, to include fees on un-included dependencies. But that
> seems fairly uncontroversial to me. It's best for users, merchants and
> miners to not leave chains of transactions in limbo when together
> their fees add up to the minimum required amount.
So, to be specific... a A->B chain of transactions, that collectively
meet the network's fee requirements? It seems quite reasonable to
accept that, sure. ACK on concept. A chain of length 2 seems like it
would be most common, and limiting total chain length (to 10? 100?)
for any one chain in the memory pool seems prudent.
As to the larger issue of fees... I will readily admit I have no good ideas.
The user's experience is pretty poor: while it might make economic
sense, from the network's standpoint, to charge for the service of
verifying and storing a transaction, the user has limited means to
determine an ideal fee. There are also other valid economic models
(receiver pays fee) out there that may successfully sustain the
network.
Ideally the fee, if any, is market based and negotiated. The current
method is loose-consensus, mainly aimed at (a) combating dust spam or
(b) ensuring it becomes increasingly more expensive to fill a block,
up to the current 1MB maximum. I think almost everyone agrees the
current fee system is an ugly, warty hack. Problem is... like
democracy, no matter how ugly it is, people have trouble finding a
better system :)
Furthermore, many of these ideas -- like sending TX's directly to the
merchant -- involve far more direct payee<->payer communication on the
part of the wallet client than is currently envisioned by the bitcoin
P2P network design, which is broadcast-oriented. So, it remains an
open question whether we want the base bitcoin layer to even worry
about real-time fee negotiation and direct TX transmission.
It is possible that an instant-payments layer evolves on top of the
base bitcoin block chain layer, with bitcoin transactions evolving
largely into settlements between instant-payment intermediaries large
and small.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
