Permalink
Browse files

Meetings: add 2017-03-09 and 2017-03-16

  • Loading branch information...
harding committed Mar 19, 2017
1 parent 1536a4d commit 1096e3fd0df13048456dc44f391afc471a962170
Showing with 279 additions and 0 deletions.
  1. +117 −0 _posts/en/meetings/2017-03-09-meeting.md
  2. +162 −0 _posts/en/meetings/2017-03-16-meeting.md
@@ -0,0 +1,117 @@
---
title: IRC meeting summary for 2017-03-09
permalink: /en/meetings/2017/03/09/
name: 2017-03-09-meeting
type: meetings
layout: page
lang: en
version: 1
---
{% include _toc.html %}
{% include _references.md %}
- [Link to this week logs](https://botbot.me/freenode/bitcoin-core-dev/2017-03-09/?msg=82192588&page=2)
- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html)
---
## Main topics
- 0.14.0 release
- Alert key disclosure timeline
- Next releases
## 0.14.0 release
Bitcoin Core 0.14.0 was released the day before the meeting. Cheers and congratulations for a successful release were shared.
## Alert key disclosure timeline
### Background
The Bitcoin alert system introduced in Bitcoin 0.3.11 has been phased out over the last several Bitcoin Core releases. For more information, please see the [public information statement][alert retirement].
In an earlier Bitcoin Core release, the alert system was redesigned to contain a hardcoded "final" alert that could be triggered in case the private key for the alert system was compromised. As part of the Bitcoin Core 0.14.0 release process, this final alert was triggered---which should have paved the path for the scheduled public release of the alert key.
### Comments
Gregory Maxwell started, "There are DOS vulnerabilities in older versions that the final alert does not block. :( All versions. They're worse in older ones. (Obviously [only] versions with alerts enabled). No RCE [Remote Code Execution], just OOM [Out Of Memory]."
According to Luke Dashjr, 2,606 nodes (4.54%) run a version of Bitcoin Core below 0.12.1. It's those versions that Maxwell identified as being vulnerable to problems related to abuse of the alerts key.
### Conclusion
Rough agreement seemed to be reached that a Common Vulnerabilities and Exposures (CVE) disclosure would be made for the denial-of-service vulnerabilities Maxwell found to further remind users of older versions of Bitcoin Core that they need to upgrade. After the CVE is distributed and the situation re-evaluated, a determination could be made on whether to disclose the alert key then.
## Next releases (0.14.1 and 0.15)
### Background
With 0.14.0 released, developers have begun tagging issues and Pull Requests (PRs) for backporting to a 0.14.1 minor release. In addition, the 0.15 release schedule has been proposed.
### Comments
Matt Corallo suggests [#9959][] and [#9955][] for 0.14.1 minor release. Nobody argued with Alex Morcos who suggested, "we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release". This means that developers will probably wait for several other bug fixes or especially useful backports to become available before producing a 0.14.1 release, keeping the schedule free to work on longer-term improvements for 0.15 and beyond.
Wladimir van der Laan proposed the 0.15 release schedule in [#9961][]. As of this writing, the schedule is:
2017-07-02
-----------
- Open Transifex translations for 0.15
- Soft translation string freeze (no large or unnecessary string changes until release)
- Finalize and close translations for 0.13
2017-07-16
-----------
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until release)
2017-08-06
-----------
- Split off `0.15` branch from `master`
- Start RC cycle, tag and release `0.15.0rc1`
- Start merging for 0.16 on master branch
2017-09-01
-----------
- Release 0.15.0 final (aim)
## Conclusion
No one objected to the proposed schedule in the meeting. Issues and PRs will continue to be tagged for backporting as 0.14.1.
## Comic relief
{% highlight text %}
<gmaxwell> There are also funds paid to the alert key in the network, I believe
0.01 BTC or so. :P
<wumpus> surprised no one ever swiped that
{% endhighlight %}
## Participants
| IRC nick | Name/Nym |
|-----------------|---------------------------|
| wumpus | [Wladimir van der Laan][] |
| gmaxwell | [Gregory Maxwell][] |
| luke-jr | [Luke Dashjr][] |
| achow101 | [Andrew Chow][] |
| sipa | [Pieter Wuille][] |
| btcdrak | [BtcDrak][] |
| morcos | [Alex Morcos][] |
| BlueMatt | [Matt Corallo][] |
| cfields | [Cory Fields][] |
| jtimon | [Jorge Timón][] |
| paveljanik | [Pavel Janik][] |
| jonasschnelli | [Jonas Schnelli][] |
## 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.
[alert retirement]: https://bitcoin.org/en/alert/2016-11-01-alert-retirement
[#9959]: https://github.com/bitcoin/bitcoin/issues/9959
[#9955]: https://github.com/bitcoin/bitcoin/issues/9955
[#9961]: https://github.com/bitcoin/bitcoin/issues/9961
@@ -0,0 +1,162 @@
---
title: IRC meeting summary for 2017-03-16
permalink: /en/meetings/2017/03/16/
name: 2017-03-16-meeting
type: meetings
layout: page
lang: en
version: 1
---
{% include _toc.html %}
{% include _references.md %}
- [Link to this week logs](https://botbot.me/freenode/bitcoin-core-dev/2017-03-16/?msg=82545921&page=3)
- [Meeting minutes by meetbot](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-16-19.01.html)
---
## 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][accounts intro] 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
{% highlight text %}
<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!
{% endhighlight %}
(Context for above: Bitcoin Core's and libsecp256k1's tests caught a bug introduced in a compiler that may have caused serious problems.)
{% highlight text %}
<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
{% endhighlight %}
## Participants
| IRC nick | Name/Nym |
|-----------------|---------------------------|
| gmaxwell | [Gregory Maxwell][] |
| wumpus | [Wladimir van der Laan][] |
| sipa | [Pieter Wuille][] |
| morcos | [Alex Morcos][] |
| jonasschnelli | [Jonas Schnelli][] |
| jnewbery | [John Newbery][] |
| jtimon | [Jorge Timón][] |
| BlueMatt | [Matt Corallo][] |
| luke-jr | [Luke Dashjr][] |
| cfields | [Cory Fields][] |
| instagibbs | [Gregory Sanders][] |
| achow101 | [Andrew Chow][] |
| bsm117532 | [Bob McElrath][] |
| kanzure | [Bryan Bishop][] |
## 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.
[accounts intro]: https://github.com/bitcoin/bitcoin/commit/e4ff4e6898d378b1a3e83791034a7af455fde3ab
[PR#9294]: https://github.com/bitcoin/bitcoin/issues/9294
[PR#8694]: https://github.com/bitcoin/bitcoin/issues/8694

0 comments on commit 1096e3f

Please sign in to comment.