cool hit counter BIP125: Addition of trading signals_Intefrankly

BIP125: Addition of trading signals


summarize

Many of today's nodes will not replace any transaction in their traffic with another transaction that spends the same input, making it difficult for the spender to adjust its previously sent transactions to handle unexpected confirmation delays or perform other useful replacements.

The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy described here allows consumers to add a signal to a transaction indicating that they wish to be able to replace it in the future. In response to this signal.

- The node allows transactions that contain this signal to be replaced in its mempools.

- The recipient containing this signal transaction will not pay for it until this signal transaction is confirmed, thereby eliminating the risk that the payer will use the permitted substitution to defraud them.

Nodes and recipients can continue to process unsignaled transactions just as they have previously processed them, thus maintaining the existing status quo.

summary

The policy sets out two ways in which a transaction can be shown to be replaceable

- Explicit signaling. If the nSequence number of any input for a transaction is less than (0xffffffff - 1), the transaction is considered to be allowed to replace itself.

- Succession signals. Transactions that do not explicitly indicate signal fungibility may be substituted under this policy, provided that either ancestor indicates fungibility and has not been proven.

Implementation details

Bitcoin Core 0.12.0 is initially expected to use the following rules.

One or more transactions currently in the mempool (the original transaction) will be replaced with a new transaction that costs one or more of the same inputs (the replacement transaction)

1. The interchangeability of the original transaction processing signal is explicitly or by inheritance, as described in the summary section above.

2. The replacement transaction does not contain any new unconfirmed input that did not previously appear in the mempool. (Unrecognized input is the output from the current unrecognized transaction output. )

3. The replacement transaction pays at least the absolute cost of the amount paid for the original transaction.

4. The replacement transaction must also pay for its own bandwidth at a rate equal to or higher than the rate set by the node's minimum relay fee. For example, if the minimum relay cost is 1 satoshi / byte and the replacement transaction totals 500 bytes, the replacer must pay at least 500 satoshis above the sum of the originals.

5. The number of original transactions and their descendants to be removed from the mempool must not exceed 100 transactions in total.

The initial implementation can be seen at https://github.com/bitcoin/bitcoin/pull/6871, in particular the master branch was committed from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive)

Receiving Wallet Policy

Wallets that display unconfirmed transactions to users or provide data about unconfirmed transactions to automated systems should consider performing one of the following actions.

- Passing on more skeptical choices of full RBF transactions to users or data consumers.

- Ignore selective trading until confirmed.

Because descendant transactions can also be replaced under this policy by inheriting signals, any methods used to process opt-in RBF transactions should be inherited by descendant transactions as long as the full RBF transaction for any ancestor join transaction remains unacknowledged.

Spending wallet policy

Wallets that do not want signal interchangeability should use either the maximum sequence number (0xffffffff) or the sequence number (0xffffffff-1) when wanting to use lock time; All known wallets currently do this. They should also be careful not to spend any clear signals on alternative or unproven transactions through genetic signatures; Most wallets also do not currently spend any unproven deals other than those they create themselves.

Wallets that want to make replacements should use clear signals and conform to the above“ Implementation rules” Criteria described in part。 Bitcoin Wiki page Already created, to help wallet authors keep track of transactions related to replacementmempool of deploy strategy。

The initial implementation uses P2P protocol rejection messages to reject substitutions, allowing P2P clients to determine whether their substitutions were initially accepted by their peers. The standard P2P lightweight client practice is to send to some peers when listening for relays from other peers, whether the replacement determined by the client has propagated.

motivations

Satoshi Nakamoto's original Bitcoin implementation provided the nSequence numeric field in each input to allow the transaction containing that input to be replaced in the mempool. When receiving a replacement, the node should replace the transaction with the higher serial number with the transaction with the lower input serial number.

In that implementation, there was no additional cost for replacement transactions, so there was no direct incentive for miners to include alternatives, nor was there a built-in rate limit to prevent overuse of relay node bandwidth. Nakamoto removed replacements from Bitcoin version 0.3.12, leaving only the comment "Replacements are now disabled".

Replacing transactions with higher-cost transactions provides a way for consumers to align their desires with those of miners, but by the time substitution fee (RBF) patches become available to re-enable substitution, some recipients begin to expect that the first version of the transaction they see may be the version of the transaction to be confirmed, so some users argue that substitution should be disabled.

To address these issues, a variant of RBF was created that requires the replacement transaction to pay the same or greater than the original transaction for all the same outputs. This is called RBF-First Seen Safe (RBF-FSS), and the initial RBF is called full RBF. While appropriate for recipients who rely on the first transaction version, each use of RBF-FSS requires additional inputs to be added to the transaction, rendering the wallet unusable and resulting in a loss of privacy if they do not have alternate inputs The waste of transaction byte sizes will increase when inputs from different sources are used in the same transaction.

Opt-in full-RBF uses Nakamoto's original semantics (slightly tweaked to allow users to opt out during lock-in time) to indicate that substitutions can be made, providing first-time users with the ability to ignore these transactions while also providing the efficiency benefits of full-RBF.

There are no known problematic interactions between opt-in full RBF and other uses of nSequence. Specifically, the full RBF is chosen to be compatible with the Bitcoin 0.1 implementation, the draft BIP68 (relative locking time using consensus enforced sequence numbers) draft and the consensus enforced locking time specified in the draft BIP112 (CHECKSEQUENCEVERIFY) draft.

deploy

Now, the first version of Bitcoin with 100% network hash rate uses selective full RBF semantics (sequence less than (0xffffffff - 1)) to mine transactions.

The choice of full RBF as the default mempool replacement strategy between nodes and miners is expected to be in the upgrade to Bitcoin Core 0.12.0 (expected to be released in January/February 2016) and will become as common as similar node software (e.g. Bitcoin LJR).

The actual substitution may be unreliable until two conditions are met.

- Enough nodes have been upgraded to support it, providing a relay path for replacing miners from spending wallets to controlling large hash rates.

- Adequate hash rates have been upgraded to support replacement, allowing for the reasonable possibility that replacement can be mined.

Customer Support

There are no known wallets that create transactions by default, where nSequence is set below (0xffffffff - 1), so there are no known existing wallets that explicitly indicate fungibility by default. There are no known popular wallets that pay by default for transactions not confirmed by other users, so there are no known existing wallets that indicate inherited fungibility.


Recommended>>
1、Todays reminder think carefully Criminals can digitize another you through ewallets mobile payments have concerns
2、The age of big data is upon us The General Office of Shandong Provincial Peoples Government included BIM in the provinces new generation of information technology industry special planning
3、Another twovowel domain name is launched ZGTOP the global version of ZGTOP goes live
4、How to deal with the irrevocable assassination gambit of the blockchain prediction market
5、Somethings fishy Youku Lovecraft Mobiles You may not even be able to cancel after registering Some log off and still deduct charges

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字,当前共

    发送中

    网络异常,请稍后重试

    微信扫一扫
    关注该公众号