[Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1
My replace-by-fee patch is now available for the v0.10.1 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1 No new features in this version; this is simply a rebase for the Bitcoin Core v0.10.1 release. (there weren't even any merge conflicts) As with the Bitcoin Core v0.10.1, it's recommended to upgrade. The following text is the copied verbatim from the previous release: What's replace-by-fee? -- Currently most Bitcoin nodes accept the first transaction they see spending an output to the mempool; all later transactions are rejected. Replace-by-fee changes this behavior to accept the transaction paying the highest fee, both absolutely, and in terms of fee-per-KB. Replaced children are also considered - a chain of transactions is only replaced if the replacement has a higher fee than the sum of all replaced transactions. Doing this aligns standard node behavior with miner incentives: earn the most amount of money per block. It also makes for a more efficient transaction fee marketplace, as transactions that are stuck due to bad fee estimates can be unstuck by double-spending them with higher paying versions of themselves. With scorched-earth techniques⁵ it gives a path to making zeroconf transactions economically secure by relying on economic incentives, rather than honesty and alturism, in the same way Bitcoin mining itself relies on incentives rather than honesty and alturism. Finally for miners adopting replace-by-fee avoids the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior, as seen in Harding's proposal⁶ that miners collectively 51% attack miners who include doublespends in their blocks - an unavoidable consequence of imperfect p2p networking in a decentralized system - or even Hearn's proposal⁷ that a majority of miners be able to vote to confiscate the earnings of the minority and redistribute them at will. Installation Once you've compiled the replace-by-fee-v0.10.1 branch just run your node normally. With -debug logging enabled, you'll see messages like the following in your ~/.bitcoin/debug.log indicating your node is replacing transactions with higher-fee paying double-spends: 2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes Additionally you can tell if you are connected to other replace-by-fee nodes, or Bitcoin XT nodes, by examining the service bits advertised by your peers: $ bitcoin-cli getpeerinfo | grep services | egrep '((0003)|(0401))' services : 0003, services : 0401, services : 0401, services : 0003, services : 0401, services : 0401, services : 0003, services : 0003, Replace-by-fee nodes advertise service bit 26 from the experimental use range; Bitcoin XT nodes advertise service bit 1 for their getutxos support. The code sets aside a certain number of outgoing and incoming slots just for double-spend relaying nodes, so as long as everything is working you're node should be connected to like-minded nodes a within 30 minutes or so of starting up. If you *don't* want to advertise the fact that you are running a replace-by-fee node, just checkout a slightly earlier commit in git; the actual mempool changes are separate from the preferential peering commits. You can then connect directly to a replace-by-fee node using the -addnode command line flag. 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/bitcoin/bitcoin/pull/3883 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html -- 'peter'[:-1]@petertodd.org 059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9 signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] CLTV opcode allocation; long-term plans?
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. I have two lines of thought on this: 1) We're going to end up with a Script v2.0 reasonably soon, probably based on Russel O'Connor and Pieter Wuille's Merkelized Abstract Syntax Tree³ idea. This needs at most a single OP_NOPx to implement and mostly removes the scarcity of upgradable NOP's. 2) Similarly in script v1.0 even if we do use up all ten OP_NOPx's, the logical thing to do is implement an actual opcode # OP_EXTENDED. 3) It's not clear what form a relative CLTV will actually take; the BIP itself proposes a OP_PREVOUT_HEIGHT_VERIFY/OP_PREVOUT_DATA along with OP_ADD, with any opcode accessing non-reorg-safe prevout info being made unavailable until the coinbase maturity period has passed for soft-fork safeness. That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Interested in your thoughts. 1) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-98568239 2) https://github.com/bitcoin/bitcoin/pull/5496 3) http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-nityas.pdf -- 'peter'[:-1]@petertodd.org 0908b2eb1cb0660069547abdddad7fa6ad4e743cebe549de signature.asc Description: Digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On 04/21/15 07:59, Peter Todd wrote: On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote: In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the height of the output being spent and then has identical semantics to CLTV. Depending on what you mean by identical this isn't actually reorg safe. For instance consider this implementation: nLockTime = stack[-1] + prevout.nHeight if (nLockTime txTo.nLockTime): return False Used with this scriptPubKey: 10 RCLTV DROP pubkey CHECKSIG If I create that output in tx1 which is mined at height 42 I can spend it in a tx2 at height 42+10 by setting tx2's nLockTime to 42+10, for instance 53. However if a reorg happens and tx1 ends up at height 43 after the reorg I'm stuck - tx2's nLockTime is set at 42. Thus RCTLV is only reorg safe if the height is compared against the actual block height of the block containing the spending transaction, not the spending transaction's nLockTime. Yes, as discussed on IRC months ago when the first email was sent, the assumption is that you would require N be at least 100. That way you are reorg safe up to the same limit as coinbase transactions, which are also only reorg safe in the case of no 100-block reorgs. Its not ideal in some contracts, but keeping the no-second-nLockTime-equivalent property is worth it IMO, and its still incredibly useful in many contracts. A slightly different API (and different name) was described by maaku at http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154 which does a better job of saving softfork-available opcode space. There are two major drawbacks to adding such an operation, however. 1) More transaction information is exposed inside the script (prior to CLTV we only had the sigchecking operation exposed, with a CLTV and RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions). 2) Bitcoin Core's mempool invariant of all transactions in the mempool could be thrown into one overside block and aside from block size, it would be valid becomes harder to enforce. Currently, during reorgs, coinbase spends need checked (specifically, anything spending THE coinbase 100 blocks ago needs checked) and locktime transactions need checked. With such a new operation, any script which used this new opcode during its execution would need to be re-evaluated during reorgs. Yup, definitely kinda ugly. If the above style of RCTLV was used, one possibility might be to make the relative locktime difference be required to be at least 100 blocks, same as the coinbase maturity, and just accept that it's probably not going to cause any problems, but could in an extremely big reorg. But re-orgs that big might be big enough that we're screwed anyway... With the 100 block rule, during a sufficiently large reorg that coinbases become unavailble, simply disconnect entire blocks - all txouts created by them. I think both of these requirements are reasonable and not particularly cumbersome, and the value of such an operation is quite nice for some protocols (including settings setting up a contest interval in a sidechain data validation operation). So to be clear, right now the minimal interface to script execution is simply: int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, unsigned int scriptPubKeyLen, const unsigned char *txTo, unsigned int txToLen, unsigned int nIn, unsigned int flags, bitcoinconsensus_error* err); Where scriptPubKey is derived from the unspent coin in the UTXO set and txTo is the transaction containing the script that is being executed. The UTXO set itself currently contains CCoins entries, one for each transaction with unspent outputs, which basically contain: nVersion - tx nVersion nHeight - Height of the block the transaction is contained in. vout - Unspent CTxOut's of the transaction. The block nTime isn't directly available through the UTXO set, although it can be found in the block headers. This does require nodes to have the block headers, but at 4MB/year growth it's reasonable to assume the UTXO set will grow faster. Script execution does not have direct access to the current block height/block time, however it does have indirect access via nLockTime. Thus we have a few possibilities: 1) RCLTV against nLockTime Needs a minimum age COINBASE_MATURITY to be safe. 2) RCLTV against current block height/time Completely reorg safe. 3) GET_TXOUT_HEIGHT/TIME diff ADD CLTV To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age
