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
|
Return-Path: <dkbryant@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 462C4910
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Dec 2017 19:55:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
[209.85.223.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2D9A54B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Dec 2017 19:55:03 +0000 (UTC)
Received: by mail-io0-f177.google.com with SMTP id n14so16046745iob.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 28 Dec 2017 11:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:reply-to:from:date:message-id:subject:to;
bh=opLxsNP61wHV2xF4Eh6xZDFAwxpvBDrAu+4v1Xtuh8c=;
b=uEr4OBU3VNh3Y0MUW1Snt2CKfLopHIw9BMtoTcxTbrIJ9CsnqdrjQ3H8jQi5Kpr6qL
MlWnHJ/MLlv2ibXV/8OZCbFPIKbIAqwMivq4xiQrChiDsuIPJexiy3ds5PbSDsL3uLu/
X+99BFErZFxfI2PquX2cpwKrHY5cupndB2xWPbMvjkzk3EYdTXmsxNkO1rf6jU8+sdWm
5IKaW/1BRIH59gjPcQK8XPhVDrUk9/Xt4D0PXxlUGIPV1XKpe6j3sKkRaT/gWveQPKub
4SLyfhpaAv3lwMs01LEH7HrTkKwNrntlc070W10Xqj3AhkSeHtigUUANGW/n+pg3X8B3
bUSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:reply-to:from:date:message-id
:subject:to;
bh=opLxsNP61wHV2xF4Eh6xZDFAwxpvBDrAu+4v1Xtuh8c=;
b=kGMb3zy68EYGx2SAgHgyq5QLvV6KsYreF2RoHPtR8tgmsuVuc3hdgAawLCjaY18SlC
h7SQKZgq16gma88ImPpir5D3T1rzns2rvK6e5pYw0mnD02lBd/UC3aNeO+2aGV4sHrch
tyElRQqf0z9lriptFbSmYRh/ClG0/iRv7ObJYpOGYYq0fzXsJB4+9nnoGGPgIguY46vj
UoaE5jN5OVZcFDgN+26ue70sEc+bGE9UXNHUwTIW2Cmp2ywSBneIqr5uunifXM3lQoAX
dE2gg8bGWitoQX/pS1/3ZiZNS3dLN8+fOULWXtKtJ3AGT2Fye6SDXwbkYU5UzFjB9S70
OprA==
X-Gm-Message-State: AKGB3mK7z6XPlxc5x+3odL9EmoK1JOmKowOCIuEGwxoDW3T/KZOnqr1F
Ib5UqxCnvaouiX4eBEVwJ13x5E2wZ62gyJkJfrU=
X-Google-Smtp-Source: ACJfBosuRtNbP29+qvlxmwovcl9iBW/FR2Z1lxorO6oHa0CjafwGrikgY8fdbrIwDmZ8apWCfbnrJ6jeng89ebDS3cs=
X-Received: by 10.107.201.1 with SMTP id z1mr43110495iof.83.1514490902190;
Thu, 28 Dec 2017 11:55:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.31.141 with HTTP; Thu, 28 Dec 2017 11:55:01 -0800 (PST)
Reply-To: DKBryant@gmail.com
From: Dan Bryant <dkbryant@gmail.com>
Date: Thu, 28 Dec 2017 13:55:01 -0600
Message-ID: <CAAUFj12x+kRUkcWECesJJRybDsQWfNL_7-D3wYexr6mOUzBY9g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0b77c03d9fe605616be496"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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
X-Mailman-Approved-At: Thu, 28 Dec 2017 20:02:56 +0000
Subject: [bitcoin-dev] Transaction aging to relieve user concerns.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 28 Dec 2017 19:55:04 -0000
--94eb2c0b77c03d9fe605616be496
Content-Type: text/plain; charset="UTF-8"
I was considering starting a BIP, but wanted to ask the thread if anything
like this was already done or in the works. My proposal is to expand the
TXN format to include chain-height (block number) in the TXN. This would
allow nodes / miners to age the TXN and choose (optionally) not to
rebroadcast it after a certain age threshold. Currently (as I understand
it), nodes and miners keep effectively a "seen-list" of TXNs and age them
based upon when they were last seen. This is very effective as it reduces
TXN size and frees the TXN from having to declare its age. The downside to
this is that those TXNs could be broadcast forever, assuming (big assume)
that the UTXO never got spent.
The goal here is not to enhance the protocol... if anything this would
increase TXN cost as it would add a few bytes to it. The goal here is to
make it easier for users to know with better certainty when an TXN is going
to age out. Obviously RBF is a better solution, but there may be some
instances when a user wants to effectively cancel a TXN.
Possible abuse vectors might include:
* Bad party broadcasting a low fee TXN at the edge of the age-out threshold
and trying to get goods, realizing the TXN will age out at the very next
block.
If this proposal might be something that core would entertain in a BIP
proposal I'll start drafting something. If there are suggestions about
where to place the block number to have minimal impact and ensure backward
compatibility, that would be great to. If this is simply silly and should
not be entertained, no harm there either.
--94eb2c0b77c03d9fe605616be496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was considering starting a BIP, but wanted to ask the th=
read if anything like this was already done or in the works.=C2=A0 My propo=
sal is to expand the TXN format to include chain-height (block number) in t=
he TXN.=C2=A0 This would allow nodes / miners to age the TXN and choose (op=
tionally) not to rebroadcast it after a certain age threshold.=C2=A0 Curren=
tly (as I understand it), nodes and miners keep effectively a "seen-li=
st" of TXNs and age them based upon when they were last seen.=C2=A0 Th=
is is very effective as it reduces TXN size and frees the TXN from having t=
o declare its age.=C2=A0 The downside to this is that those TXNs could be b=
roadcast forever, assuming (big assume) that the UTXO never got spent.<div>=
<br></div><div>The goal here is not to enhance the protocol... if anything =
this would increase TXN cost as it would add a few bytes to it.=C2=A0 The g=
oal here is to make it easier for users to know with better certainty when =
an TXN is going to age out.=C2=A0 Obviously RBF is a better solution, but t=
here may be some instances when a user wants to effectively cancel a TXN.</=
div><div><br></div><div>Possible abuse vectors might include:</div><div><br=
></div><div>* Bad party broadcasting a low fee TXN at the edge of the age-o=
ut threshold and trying to get goods, realizing the TXN will age out at the=
very next block.</div><div><br></div><div>If this proposal might be someth=
ing that core would entertain in a BIP proposal I'll start drafting som=
ething.=C2=A0 If there are suggestions about where to place the block numbe=
r to have minimal impact and ensure backward compatibility, that would be g=
reat to.=C2=A0 If this is simply silly and should not be entertained, no ha=
rm there either.</div></div>
--94eb2c0b77c03d9fe605616be496--
|
