Weird gettransaction details on testnet with segwit #11048

This is on testnet:

$ bitcoin-cli getnewaddress
mtDEt17M5zmYKpnw6jySu5yKQzSEUDkgAR

$ bitcoin-cli addwitnessaddress mtDEt17M5zmYKpnw6jySu5yKQzSEUDkgAR
2MzysLfegPX9ZFDS9W2Bv9jh5MgmvTE5VUC

Then got some money sent to that address, and then sent it to myself using the gui with a custom change address of the same address:

https://testnet.smartbit.com.au/tx/0523ca1832220dee772216f4d3ba429df66963eb770829b146059fbea1a24da4

(Which gives an incorrect error in the gui: <img width="1115" alt="screen shot 2017-08-14 at 3 38 27 pm" src="https://user-images.githubusercontent.com/9326759/29291423-2a299436-8109-11e7-979e-b5f82cce9b22.png"> but that's a minor issue)

Now:

$ bitcoin-cli gettransaction 0523ca1832220dee772216f4d3ba429df66963eb770829b146059fbea1a24da4

{
  "amount": 0.00000000,
  "fee": -0.00073595,
  "confirmations": 3,
  "blockhash": "00000000000003b2aecdcc2f7fd00399399b48790625b8c2fd61fc4431e49302",
  "blockindex": 10,
  "blocktime": 1502743284,
  "txid": "0523ca1832220dee772216f4d3ba429df66963eb770829b146059fbea1a24da4",
  "walletconflicts": [
  ],
  "time": 1502743130,
  "timereceived": 1502743130,
  "bip125-replaceable": "no",
  "details": [
    {
      "account": "",
      "address": "2MzysLfegPX9ZFDS9W2Bv9jh5MgmvTE5VUC",
      "category": "send",
      "amount": -0.04981599,
      "label": "",
      "vout": 0,
      "fee": -0.00073595,
      "abandoned": false
    }, 
    {
      "account": "",
      "address": "2MzysLfegPX9ZFDS9W2Bv9jh5MgmvTE5VUC",
      "category": "send",
      "amount": -0.00500000,
      "label": "",
      "vout": 1,
      "fee": -0.00073595,
      "abandoned": false
    }, 
    {
      "account": "",
      "address": "2MzysLfegPX9ZFDS9W2Bv9jh5MgmvTE5VUC",
      "category": "receive",
      "amount": 0.04981599,
      "label": "",
      "vout": 0
    }, 
    {
      "account": "",
      "address": "2MzysLfegPX9ZFDS9W2Bv9jh5MgmvTE5VUC",
      "category": "receive",
      "amount": 0.00500000,
      "label": "",
      "vout": 1
    }
  ],
  "hex": "020000000001019babaddea139f754e38cec18c4a83eccda4c288e35958ee1f8532e23a381a7a401000000171600148b3ffe1b7702bd4b683ab5aee9c955f8baa0097dfdffffff025f034c000000000017a91454d987c10cb670b594953f5fcfaa881c0a644bc58720a107000000000017a91454d987c10cb670b594953f5fcfaa881c0a644bc5870248304502210095d3dd05c1f79cf8c9c1d8fbe01e2ccd391a2d74117fa0c3fad4049f1a1aa16602207d39d152197cc95ab910aa09426998f311c6f1e5b53e17b894c55f86f4023be6012103e5a52b4575dbfb507a708e482c3921ebd057944133093c4679ad0e0b29bae894bdf91100"
}

There's a couple issues:

bip125-replaceable": "no",

While in my bitcoin.conf was: walletrbf=1 but also look at the details it shows 2 sends when there should only be 1.

Are you running 0.14 or master?

v0.14.2

There's a couple issues: bip125-replaceable": "no",

I can answer this one -- confirmed transactions are not bip125 replaceable, because they are confirmed.

The send output looks correct to me...we could possibly merge "send" listings if they both went to the same recipient but normally that is what you'd want - 2 send listings for the two outputs you sent to. We could update the docs to note this behavior, however.

As for it listing them at all since they're yours, well addwitnessaddress is, as yet, unsupported and may behave weirdly. 0.15.1 should resolve this fully (at which point I assume this bug can be closed).

And I can explain the rest: A send to self is not hidden unless it is to an address from the change pool, and the added address is not a change pool key. This causes awkward behavior from the "custom change" feature, for sure-- but my advice there would be to not use that. :)

To understand why send to self are not hidden unless they're change pool keys imagine a service with multiple users where users can direct sends and get deposits. If one user withdraws to another users address and it were treated as change, funds would vanish.

One could argue that the custom change thing could annotate the transaction with an exception of some kind... but it wouldn't be durable across recovery and would add a lot of complexity, thus the "don't use that" recommendation.

Oh, and some extra color as to why the BIP125 flag works like that: It's pedantically true (BIP125 doesn't allow replacing a confirmed transaction) but mostly we were concerned that some merchants might ignore payments which were BIP125 replaceable .... even after they were long confirmed and hoped that switching to no would reduce how often that particular error was made.

Removed 0.16.0 milestone after discussion on IRC.

Well, we could have it add a simple "comment" in theory, but I'm not sure it's a priority for something that really has no normal use case.

Closing, since

• the rbf thing is not a bug
• segwit wallet will support "segwit change"
• Expert features (addwitnessaddress and coin control) are usually fine to not be as much documented as user features

If someone feels obliged to amend the tooltip to mention that the wallet treats it as "normal send" when the address is not from the change keypool, they should open a new issue or better, file a pull request.