BUIP004 (passed A1): RBF/double spending support

[Roy Badami]

Ok, my post on ths got way to long to fit in a reply, so I've posted it here.

https://gist.github.com/roybadami/7bd2ea56a06984fedace

It's pretty rough and ready (I've not had time to proofread it) but I though it worth posting what I've written regardless.

Comments/corrections most welcome.

 

[solex]

@Roy Badami

It's really helpful to see your write-up which is by far the most authoritative treatment on RBF thus far. I have just given it a 2nd reading to think about all the points you raise. It is clear that there are pros and cons to all the flavours of RBF and the best long-term approach for BU to opt-in RBF is uncertain depending upon the level of take-up by mining and non-mining nodes.

Your recommendation of P1 is wise, and perhaps @Inca can more explicitly offer this in BUIP004 before the vote.

You mention your write-up is rough, but if it were a bit more formalized like a paper I think it would be valuable to have it as a permanent addition to the bitcoinunlimited.info resources page
http://www.bitcoinunlimited.info/resources.html

 

[seweso]

Interesting discussion is also going on here:

https://bitcoinclassic.consider.it/revert-opt-in-rbf?results=true

Bitcoin unlimited can probably also request their own consider.it page.

 

[solex]

Classic is going to implement v0.12 without RBF

https://bitcoinclassic.slack.com/archives/welcome/p1453231933005812

@Inca what are your thoughts on @Roy Badami's write-up, particularly P1? For the purpose of voting on BUIP004 can the BU Developer deem option A1 the same as P1 the same as Classic's disabling of opt-in RBF...?

 

[bitcartel]

Core has just added an option to optionally enable opt-in RBF so that a node's mempool will accept RBF transactions with the default setting being true.

https://github.com/bitcoin/bitcoin/pull/7386

You might want to read that over a few times

 

[theZerg]

I agree with @Roy Badami and classic -- essentially to keep the 0.11 behaviour (no RBF) for now. As nearly as I can tell, this position maps to a vote for option "A1" in the BUIP.

While there is good reason to go with the XT idea (relay the txns so nodes know they are being cheated but don't mine them), right now no miners are running BU AFAIK. So I think that we should go with something simple (revert the opt-in changes) that makes BU take the political position we want it to.

 

[solex]

VOTING IS OPEN for this BUIP

If you are in the membership then please go to this thread to cast your vote:

### VOTING IS OPEN for BUIPs 2, 4, 5, 10 & 13 ###

Note that BUIP004 has options A1, A2, B, C

 

[Aquent]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aquent votes on Bitcoin Unlimited BUIPs on Saturday, Jan 30th 2016,
on the web forum bitco.in/forum:

BUIP002: FOR
BUIP004: FOR A1
BUIP005: FOR
BUIP010: FOR
BUIP013: AGAINST
END

Just added a comment to the BUIP013 thread for my voting against reasons.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWrLguAAoJED0k2w2yfJ7TwCwH/jFne/OaYJkD/IydERHAeL3Y
IKqEfE5sUzt/GsN3lwKNtfGzwffqyXxUS2ypRnFPb048Bv6K3U22F43Euh5ciwak
YS1X8NbTxqJC1O8HSorNETQpp++sekTcDaBzKzcrMjFMPJvhFZaPeJhX9HFBkxAl
o7xfjTzNqfbvgpvW8AIMLqb/2OJN4bnBjtha3OsEZduF/+w3w+LAKYd3fRmAk9EE
R2e7e8w1nF8Va06oEpI2khhN3kMwJ2h8J/GcbiJvHRV/8GxnJ8Ca2xQlSERl8qVN
thErJs5oYl5cpoXrbG2mlOmAG8RlKGHFdDasqoxdlYv9b0pNnap9qCj1qG8mAHc=
=ynLn
-----END PGP SIGNATURE-----

 

[solex]

Voting for BUIP004 is now closed

 

[theZerg]

Looking for a quick review of the code to disable RBF:

https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/8bedc2e6d937412ef362519e9a6c02221a44c2a7

Also, developers what's your opinion on what I should do with the tests. We WANT the RBF tests to fail... should I change the "sense" of every RBF test to reflect this or just let it fail as shown here:


bu/qa/rpc-tests $ python replace-by-fee.py
Initializing test directory /tmp/testkJ2B2B
Running test simple doublespend...
JSONRPC error: 258: txn-mempool-conflict
File "/me/bitcoin/bu/qa/rpc-tests/test_framework/test_framework.py", line 135, in main
self.run_test()
File "replace-by-fee.py", line 93, in run_test
self.test_simple_doublespend()
File "replace-by-fee.py", line 149, in test_simple_doublespend
tx1b_txid = self.nodes[0].sendrawtransaction(tx1b_hex, True)
File "/me/bitcoin/bu/qa/rpc-tests/test_framework/coverage.py", line 44, in __call__
return_val = self.auth_service_proxy_instance.__call__(*args, **kwargs)
File "/me/bitcoin/bu/qa/rpc-tests/test_framework/authproxy.py", line 140, in __call__
raise JSONRPCException(response['error'])
Stopping nodes
Cleaning up
Failed

 

[TrevinHofmann]

It's usually not a good idea to expect tests to fail. Tests should be modified to pass under the new expected behavior.

 

[theZerg]

Ofc its not "usually" a good idea. But this is a very special situation. It might be best to comment out replace-by-fee.py in any automated suites and add a new file no-replace-by-fee.py... that has a few negative tests.

 

[YarkoL]

If RBF is a missing feature, then no sense in including the test file.
No need to verify the expected result of non-existent feature failing either,
as long as the choice to use the said feature depends on user only.

 

[TrevinHofmann]

I agree with @YarkoL. If the feature is to be removed completely, remove the code and the tests for it. Having unreachable / disabled code is messy, and expecting tests to fail is confusing.