path: root/f0/893fc94c5496bd18cd9638c49f0da071359caf

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tomh@thinlink.com>) id 1YxJUk-00065w-Bw
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 18:22:30 +0000
X-ACL-Warn: 
Received: from mail-pa0-f54.google.com ([209.85.220.54])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YxJUi-0002Cd-LB
	for bitcoin-development@lists.sourceforge.net;
	Tue, 26 May 2015 18:22:30 +0000
Received: by pacwv17 with SMTP id wv17so98606076pac.2
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 26 May 2015 11:22:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=AX1Mb3hmF3dPqJpSzRoHAoy1u9TIsOvMf1dnU8JjDek=;
	b=Lbm2v10wMcPMJHsej8Dv4175q7yu9UCm5MHGt80s4vKKRs02lfSHsJ0nJ/c4na29Pl
	A/Z2QGzpQYIlEuX7M2qRXMGHvNTmLL4/L+1gK4nOzr8GE9CFwa+DkrU2qwnD3GKq3tUB
	QypA2a/MeGqi55ZBs5GzQWKiNFRw3hwh7Nnh3TSh+3Xarkq/wv/T7FHyrbu8Q/64TlMa
	MDYpvCNOTu37nypk5ZIjj98o+7eIJF63/xafwJn8nCMLw70ta3PDRDwpvOpVNPDyk3sk
	cO7LsZnNbK+ieboW3Q0XD0KoSPU7o9fVb3gTmi6ras/FqXbmtG/FgpN/y8FfXCG/Qc1F
	jXvA==
X-Gm-Message-State: ALoCoQkPHbHnvEqVxlJf9dkIbl/UYO5g+x2eVziYIoR3RttbsYU0tz/YK7jhBqbWI5JwRb0TVoJf
X-Received: by 10.70.56.98 with SMTP id z2mr50325320pdp.120.1432662871220;
	Tue, 26 May 2015 10:54:31 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
	by mx.google.com with ESMTPSA id
	ux4sm13673148pbc.61.2015.05.26.10.54.29
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 26 May 2015 10:54:30 -0700 (PDT)
Message-ID: <5564B33D.3070107@thinlink.com>
Date: Tue, 26 May 2015 10:54:05 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <20150526051305.GA23502@savin.petertodd.org>
In-Reply-To: <20150526051305.GA23502@savin.petertodd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
	[204.58.254.99 listed in dnsbl.sorbs.net]
X-Headers-End: 1YxJUi-0002Cd-LB
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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: Tue, 26 May 2015 18:22:30 -0000


I think this is a significant step forward.

I suggest you also need to ensure that no inputs can be removed or 
changed (other than scriptsigs) -- only added.  Otherwise, the semantics 
change too much for the original signers.  Imagine a tx with two inputs 
from different parties.  Should it be easy for party 1 to be able to 
eliminate party 2 as a contributor of funds?  It's not difficult to 
imagine real-world consequences to not having contributed to the 
transaction.  And unless you can think of a reason, tx-level attributes 
like nLocktime should not change either.

The result would be something very like CPFP, but with the new inputs 
and outputs merged into the original tx, keeping most of the overhead 
savings you describe.

It should be submitted to bitcoin/bitcoin because like most inconsistent 
relay policies, inconsistently deployed FSS RBF invites attacks (see 
https://gist.github.com/aalness/a78e3e35b90f52140f0d).

Generally, to be kind to zeroconf:

  - Align relay and validation rules
  - Keep first-seen
  - Relay double-spends as alerts
  - Allow nLocktime transactions into the mempool a bit before they 
become final
  - ...

It's not unlike making a best-effort to reduce sources of malleability.  
FSS RBF should be compatible with this if deployed consistently.



On 5/25/2015 10:13 PM, Peter Todd wrote:
> Summary
> -------
>
> First-seen-safe replace-by-fee (FSS RBF) does the following:
>
> 1) Give users effective ways of getting "stuck" transactions unstuck.
> 2) Use blockchain space efficiently.
>
> without:
>
> 3) Changing the status quo with regard to zeroconf.
>
> The current Bitcoin Core implementation has "first-seen" mempool
> behavior. Once transaction t1 has been accepted, the transaction is
> never removed from the mempool until mined, or double-spent by a
> transaction in a block. The author's previously proposed replace-by-fee
> replaced this behavior with simply accepting the transaction paying the
> highest fee.
>
> FSS RBF is a compromise between these two behaviors. Transactions may be
> replaced by higher-fee paying transactions, provided that all outputs in
> the previous transaction are still paid by the replacement. While not as
> general as standard RBF, and with higher costs than standard RBF, this
> still allows fees on transaction to be increased after the fact with
> less cost and higher efficiency than child-pays-for-parent in many
> common situations; in some situations CPFP is unusable, leaving RBF as
> the only option.
>
>
> Semantics
> ---------
>
> For reference, standard replace-by-fee has the following criteria for
> determining whether to replace a transaction.
>
> 1) t2 pays > fees than t1
>
> 2) The delta fees pay by t2, t2.fee - t1.fee, are >= the minimum fee
>     required to relay t2. (t2.size * min_fee_per_kb)
>
> 3) t2 pays more fees/kb than t1
>
> FSS RBF adds the following additional criteria to replace-by-fee before
> allowing a transaction t1 to be replaced with t2:
>
> 1) All outputs of t1 exist in t2 and pay >= the value in t1.
>
> 2) All outputs of t1 are unspent.
>
> 3) The order of outputs in t2 is the same as in t1 with additional new
>     outputs at the end of the output list.
>
> 4) t2 only conflicts with a single transaction, t1
>
> 5) t2 does not spend any outputs of t1 (which would make it an invalid
>     transaction, impossible to mine)
>
> These additional criteria respect the existing "first-seen" behavior of
> the Bitcoin Core mempool implementation, such that once an address is
> payed some amount of BTC, all subsequent replacement transactions will
> pay an equal or greater amount. In short, FSS-RBF is "zeroconf safe" and
> has no affect on the ability of attackers to doublespend. (beyond of
> course the fact that any changes what-so-ever to mempool behavior are
> potential zeroconf doublespend vulnerabilities)
>
>
> Implementation
> --------------
>
> Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176
>
> A backport to v0.10.2 is pending.
>
> An implementation of fee bumping respecting FSS rules is available at:
>
> https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py
>
>
> Usage Scenarios
> ---------------
>
> Case 1: Increasing the fee on a single tx
> -----------------------------------------
>
> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
> with the minimal relay fee, 2.26uBTC. Increasing the fee while
> respecting FSS-RBF rules requires the addition of one more txin, with
> the change output value increased appropriately, resulting in
> transaction t2, size 374 bytes. If the change txout is sufficient for
> the fee increase, increasing the fee via CPFP requires a second
> 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another
> input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total
> of 566 bytes.
>
> Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in
>            cases where the original transaction didn't have a change
>            output.
>
>
> Case 2: Paying multiple recipients in succession
> ------------------------------------------------
>
> We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice.
> We now need to pay Bob. With plain RBF we'd just add a new outptu and
> reduce the value of the change address, a 90% savings. However with FSS
> RBF, decreasing the value is not allowed, so we have to add an input.
>
> If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can
> be created, 2*226=452 bytes in total. With FSS RBF we can replace t1
> with a 2-in-3-out tx paying both, increasing the value of the change
> output appropriately, resulting in 408 bytes transaction saving 10%
>
> Similar to the above example in the case where the change address of t1
> is insufficient to pay Bob the end result is one less transaction output
> in the wallet, defragmenting it. Spending these outputs later on would
> require two 148 byte inputs compared to one with RBF, resulting in an
> overall savings of 25%
>
>
> Case 3: Paying the same recipient multiple times
> ------------------------------------------------
>
> For example, consider the situation of an exchange, Acme Bitcoin Sales,
> that keeps the majority of coins in cold storage. Acme wants to move
> funds to cold storage at the lowest possible cost, taking advantage of
> periods of higher capacity. (inevitable due to the poisson nature of
> block creation) At the same time they would like to defragment their
> incoming outputs to keep redemption costs low, particularly since
> spending their high-security 3-of-7 P2SH multisigs is expensive. Acme
> creates a low fee transaction with a single output to cold storage,
> periodically adding new inputs as funds need to be moved to storage.
> Estimating the cost savings here is complex, and depends greatly on
> details of Acme's business, but regardless the approach works from a
> technical point of view. For instance if Acme's business is such that
> the total hotwallet size needed heavily depends on external factors like
> volatility, as hotwallet demand decreases throughout a day they can add
> inputs to the pending transaction. (simply asking customers to deposit
> funds directly to the cold storage is also a useful strategy)
>
> However this is another case where standard RBF is significantly more
> useful. For instance, as withdrawal requests come in the exchange can
> quickly replace their pending transactions sending funds to cold storage
> with transactions sending those funds to customers instead, each time
> avoiding multiple costly transactions. In particular, by reducing the
> need to access cold storage at all, the security of the cold-stored
> funds is increased.
>
>
> Wallet Compatibility
> --------------------
>
> All wallets should treat conflicting incoming transactions as equivalent
> so long as the transaction outputs owned by them do not change. In
> addition to compatibility with RBF-related practices, this prevents
> unnecessary user concern if transactions are mutated. Wallets must not
> assume TXIDs are fixed until confirmed in the blockchain; a fixed TXID
> is not guaranteed by the Bitcoin protocol.
>
>