From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 462C4910 for ; 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 ; Thu, 28 Dec 2017 19:55:03 +0000 (UTC) Received: by mail-io0-f177.google.com with SMTP id n14so16046745iob.4 for ; 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 Date: Thu, 28 Dec 2017 13:55:01 -0600 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.
=
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.

Possible abuse vectors might include:
* 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.

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.
--94eb2c0b77c03d9fe605616be496--