IRC meeting summary for 2017-03-16

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• How the wallet should deal with long chains of unconfirmed transactions
• Status of removal of account system
• Revising make check tests

How the wallet should deal with long chains of unconfirmed transactions

Background

Bitcoin Core allows its wallet users to create chains of unconfirmed transactions. For example, transaction C spends the change from transaction B, which itself spends the change from transaction A.

If you create a chain of more than 20 unconfirmed transactions this way, Bitcoin Core 0.14.0 will (by default) reject any new transactions you create on that chain. This is because other logic in Bitcoin Core doesn’t allow chains of more than 20 transactions into its mempool as protection against other people abusing your node’s resources.

At the time of the meeting, at least two separate people have opened issues about this, wondering why they can’t create transactions.

Alternatively, Bitcoin Core used to allow users to create a chain of more than 20 unconfirmed transactions, but simply didn’t relay the ones over 20 deep or add them to the mempool until some of their ancestors had been confirmed. This meant that when you create that 21st transaction, your wallet deducts the amount you spent (your input) but doesn’t immediately credit you with any change outputs.

For example, if you spend a 10 BTC input to a 0.1 BTC output, you would expect your balance to go down by 0.1 BTC—but instead it goes down by 10 BTC until at least one of the earlier 20 transactions is confirmed.

As a compromise, Bitcoin Core 0.14.0 provides a command-line option that allows users to choose which behavior they want: the default limit of 20 chained transactions or unlimited chained transactions with delayed balance updates.

This issue had already been discussed quite a bit among developers, and none of the developers who spoke about it in the meeting were satisfied with the current behavior—but nobody so far had proposed a solution that would provide a good user experience without requiring significant code changes to handle this fairly rare case.

In addition, the whole situation is aggravated by the continued presence of transaction malleability on the network for regular wallet transactions. If an ancestor transaction is mutated, none of its descendants will be valid on the same block chain. No money is lost in this case, but the wallet needs a way to learn that those descendant transactions are now invalid and update the wallet balance accordingly.

Comments

In attempting to describe the problem, Alex Morcos said, “it’s kind of hard to have this discussion on a PR”. It also seemed hard to discuss in IRC based on the amount of confusion during the chat.

Gregory Maxwell suggested, “This is a sign that our current definition is just broken. It should not be so tightly coupled to the mempool (like how is the software even supposed to be usable to people that don’t have a mempool? – this is a supported configuration!).”

Pieter Wuille replied, “if you don’t rely on the mempool, it’s not that hard I think to make the wallet double count,” with Wladimir van der Laan expanding, “so if it sends a transaction, and someone malleates it and it would receive the malleated version back, it’d count that double.”

Wuille also added, “wallets that don’t spend unconfirmed change don’t have this problem”.

Discussion sidetracked for a while on fee bumping and then returned to the main topic with Maxwell pointing out that, “without malleablity basically none of these change handling issues would exist, I think, as you’d never have a case where you might double count your own funds.”

Conclusion

After more than half an hour of discussion on the issue, Morcos suggested, “ok, we’re going off the rails. now - maybe next topic, and we revisit this in a week after thinking through both avenues,” which received hearty approval from all the meeting participants.

Status of removal of account system

Background

By late 2010, several websites were offering web wallets and exchanges that were basically a thin layer on top of the Bitcoin software (it wasn’t called Bitcoin Core yet). During that time, Bitcoin introduced an accounts system that allowed a single Bitcoin instance to keep track of balances in multiple accounts.

Later web wallets and exchanges implemented their own accounting backends and Bitcoin Core’s accounts system has mostly been unused since then—yet it complicates many RPC calls and isn’t particularly useful for anything besides running a multi-user web wallet. (An upcoming feature, multi-wallet, will provide true wallet separation for users who want to partition different sets of bitcoins.)

So for the last several releases, all features related to the accounts system have been marked as deprecated and are either being removed or converted back to the label system from which accounts originated.

Discussion

Wladimir van der Laan summed up the status: “can be really short there: no advances since last time we’ve discussed that, as we need a label API first before even thinking about deprecating accounts.”

Matt Corallo said, “this should definitely happen for 0.15, IMO [in my opinion],” To which Wladimir agreed but added, “I agree, though multiwallet has higher priority for me.”

Discussion then moved to topics about multi-wallet, mainly what pull requests would be useful for developers to review this week, including PR#9294 and PR#8694.

Conclusion

Review above pull requests to make progress on multiwallet and work on on a label API for account system removal.

Revising make check tests

Background

Bitcoin Core provides a makefile target check that runs the project’s unit tests. The project has over time written more and more integration tests executed through the RPC interface, which are run automatically by the Travis Continuous Integration (CI) server that tests every Bitcoin Core pull request and which can manually be run by executing, qa/pull-tester/rpc-tests.py

Discussion

Jonas Schnelli asked, “What’s the benefits of adding the rpc’s to make check?”

Wladimir van der Laan replied, “‘make check’ should ideally do fairly quick checks, some of the RPC tests classify as that, but the whole suite takes maybe too long.”

Discussion continued about ensuring that make check runs reasonably fast, including increasing the ability to run it on multiple CPU cores.

Conclusion

John Newberry concluded, “ok, sounds like there’s no fundamental objection to at least doing some RPC tests in make check. I’ll open a PR and we can continue discussion there.”

Comic relief

<wumpus> gmaxwell: yup. don't know if you saw the clang fsafe-stack
         issue that messes up deterministic signing

<gmaxwell> wumpus: I didn't.

<wumpus> gmaxwell: let me dig it up
         gmaxwell: https://github.com/bitcoin-core/secp256k1/issues/445

<gmaxwell> wumpus: holy fuck!

(Context for above: Bitcoin Core’s and libsecp256k1’s tests caught a bug introduced in a compiler that may have caused serious problems.)

<gmaxwell> without malleablity basically none of these change handling issues
           would exist, I think.
           as you'd never have a case where you might double count your
           own funds.

<wumpus> unfortunately we're stuck with malleability

<morcos> not if we use flextrans
         (sorry)

<gmaxwell> hah

<jonasschnelli> heh

<wumpus> flextrans, lol

<BlueMatt> trolol

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.