Most wallets have something where you can add more recipients (i.e. more addresses). Electrum does a thing where you put all of the addresses in a list with the amount you want to send to each address following the address.

You are attempting to predict the future, literally an impossible task. It is impossible to know what would happen if either Segwit is deployed or if BU takes over. Any answer you get here will be pure and absolute speculation.

Can you please post the dbLog.txt file?

I believe this is the same problem that I ran into a while ago. There are no configuration options that you can do to fix this, you will need to build the software from the source code. I have a patch here: https://github.com/goatpig/BitcoinArmory/pull/158 that should fix the problem.

Every one hundred addresses. This usually is every 100 transactions as you use one change address when sending and one address when receiving.

Even with the new HD wallets, you should still backup every 100 addresses so that you keep any metadata and not miss any addresses that you have previously used.

If you made more than one hundred addresses, with the old wallets, you will lose some Bitcoin from the addresses after 100. With the HD wallets, you will have to extend the keypool and possibly rescan so that you get all of the transactions.

Fixed that. Really the only reason is "frequent contributor". Now, if you are a frequent contributor to a specific set of functionality, you become the maintainer for that stuff and get commit access. But still, it is for being a frequent contributor.

I am creating this thread in response to the discussion occurring at https://bitcointalk.org/index.php?topic=1773558.msg17697805#msg17697805. This list will contain the names (or pseudonyms) of everyone who I can find evidence for ever having commit access to Bitcoin Core, the dates during which they had commit access, sources for all of this information, and reasoning for the access. Those who currently have commit access are in bold.

• Satoshi Nakamoto (satoshi, s_nakamoto): 2009-01-03 - 2011-09-13^[1] Creator, first Lead Maintainer
• Martti Malmi (Sirius, sirius_m): 2009-08-30 - 2011-09-13^[1][2]    Creator of first SVN repo
• Laszlo (laszloh) 2010-08-04 - 2011-09-131^[1]    Original OSX Builds and support
• Gavin Andresen (gavinandresen): 2010-10-11 - 2016-05-02^[3]    Frequent contributor; later Lead Maintainer
• Chris Moore (dooglus): 2011-01-21 - 2011-03-31    Frequent contributor for some time; Still occasionally contributes
• Pieter Wuille (sipa): 2011-05-01 - 2022-07-07    Frequent contributor
• Jeff Garzik (jgarzik): 2011-05-06 - July/Aug 2016 ^[4]    Frequent Contributor
• Wladimir J. van der Laan (laanwj, wumpus): 2011-06-05 - present^[5]    Frequent contributor; later Lead Maintainer
• Nils Schneider (tcatm): 2011-09-19 - 5/31/12    Frequent contributor for some time
• Greg Maxwell (gmaxwell): 2012-02-11 - 2015-12-17    Frequent contributor; Gave up commit access due to toxicity and drama from the community
• Jonas Schnelli (jonasschnelli): 2015-11-13 - 2021-10-21^[6]    Frequent contributor; given access after becoming GUI Maintainer; Stepped down for personal reasons
• Marco Falke (marcofalke): 2016-04-13 - present^[7]    Frequent Contributor; given access after becoming QA/Testing Maintainer
• Samuel Dobson (MeshCollider): 2018-12-06 - 2021-09-12^[8]    Frequent Contributor; given access after volunteering to be the wallet maintainer; Stepped down to focus on his PhD
• Michael Ford (fanquake): 2019-06-08 - present^[9]    Frequent Contributor; given access after being nominated by several other frequent contributors and maintainers to become a maintainer.
• Hennadii Stepanov (hebasto): 2021-04-19 - present  Frequent Contributor; given access after volunteering to help maintain the GUI
• Andrew Chow (achow101): 2021-12-20 - present^[10]     Frequent Contributor; given access after volunteering to be the wallet maintainer.
• Gloria Zhao (glozow): 2022-07-07 - presentt^[11]    Frequent contributor, given access after being nominated by several frequent contributors and maintainers to become a maintainer.

Footnotes:

• [1] The move to Github occurred before the last SourceForge commit, but the last SourceForge commit declares sourceforge as dead. Presumably those who only committed to SourceForge no longer had commit access after the move
• [2] Sirius was the one who created the original SVN repo on SourceForge.
• [3] Gavin was the Lead Maintainer from 2011-02-23 until 2014-04-07
• [4] I cannot find anything that suggests that Jeff Garzik has given up his commit access or has had it revoked I was informed via IRC PM by some of the Core devs that Jeff's commit access was revoked some time around August 2016 after several months of inactivity.
• [5] Wladimir is the current Lead Maintainer. After participating in that role for a long time, he was officially given the position by Gavin on 2014-04-07
• [6] Jonas is currently the GUI Maintainer. After participating in that role for a long time, he was officially given the position by Wladimir on 2015-11-13. He stepped down for personal reasons.
• [7] Marco is currently the QA/Testing Maintainer. After participating in that role for a long time, he was officially given the position by Wladimir on 2016-04-13
• [8] MeshCollider was the Wallet Maintainer. He had been contributing for a while, particularly to wallet related things. When laanwj asked if anyone would like to be the role of Wallet Maintainer, MeshCollider volunteered. He url=https://twitter.com/meshcollider/status/1469024214535393282]stepped down[/url] to focus on his PhD.
• [9] fanquake is currently the Build System Maintainer as well as a general maintainer. He had been contributing for a while, particularly with updating dependency versions and build system related things. He also had been doing a lot of janitorial things in the repo such as tagging issues, closing old issues and PRs, nominating things to be merged, etc. At the CoreDev event in Amsterdam which several maintainers and contributors attended, he was nominated to be a maintainer by the entire group.
• [10] achow101 has contributed to the project for many years, especially in wallet and PSBT-related areas. After meshcollider stepped down from the Wallet Maintainer role, achow101 volunteered to taked up the role.
• [11] glozow has contributed to the project for a few years, particularly in the mempool and node policy areas. She was nominated by fanquake to be a maintainer with focus in those areas.

Other Notes:

• Dates are Year-Month-Day
• There may be people missing and dates may be slightly incorrect. These are all that I can determine by looking at old emails and the commit history. Please let me know if anything is incorrect
• The start date is determined by the first merge commit made by that person. The end date is determined by the date of the last merge commit made by that person or other announcements of commit access revocation.

---

After scrolling through nearly the entire git merges history, I have found a couple of interesting things.

Satoshi did not use a Version Control System originally. The releases and source code were originally in a rar file that was uploaded to bitcoin.org. Sirius had to setup the original SVN repository on SourceForge for him. This was then later migrated to GitHub by Gavin. Originally patches were authored by developers and then emailed to Satoshi, Sirius, or Gavin who then committed the changes to the source tree with the commit message containing the attribution, but not the actual commit itself.

Another interesting fact is that the giving out of commit access has become more strict. It is now a privilege held by those given maintainer positions and those whose privilege was grandfathered in (i.e. they had it previously and kept it, until otherwise revoked). Previously it was simply given out to those who contributed frequently and revoked after they stopped contributing. This appears to be no longer the case, although there are still multiple people who can commit to the repository so that there is not any reliance on one person. The maintainers are still given to frequent contributors as the maintainers are frequent contributors to the set of functionality for which they are maintainers of. They received the positions because of frequent contributions to those functionalities. Of those whose commit access was grandfathered, only Pieter Wuille remains - the rest were revoked eventually primarily for the lack of contributions (see each individual for their specific reason).

Lastly, I could not find any evidence for Satoshi ever publicly announcing that Gavin was to be the Lead Maintainer after him. It seems that Gavin was already a frequent contributor and already had commit access for a while before Satoshi disappeared. After Satoshi disappeared and Sirius stopped contributing as much, Gavin simply took over the role as lead maintainer as he was the only frequent contributor with commit access.

---

Edits: This has been posted to reddit where the people on this list are more active.
This list has been posted on Bitcoin stackexchange as well
Dooglus -> dooglus
Jeff's commit access was revoked a while ago
Bolded active contributors
Clarified how maintainers got their roles

This is simply untrue. I know for a fact that during Gavin's maaintainership Dooglus had commit access for a time. Furthermore, I am pretty sure that Sirius also had commit access while Satoshi was around.


The people I listed are definitively known to have commit access (except Sirius). They were just the ones that I could name off of the top of my head. You can also just look at the git repository and see who has made a merge commit. That will give you a list of everyone who has had commit access.

I can give it a more definitive list once I get back to my computer as I am currently on mobile.

Wladimir, Pieter Wuille, Marco Falke, Jonas Schnelli all have commit access. The may be more. I'm fairly certain they all got their merge access before Wladimir was maintainer.

What happens is some developers create the changes and submit a pull request. The code is then reviewed, and if enough regular contributors agree that the changes should be merged, then they will be merged. In order for that to happen though, a couple of things generally have to happen. First, as a general rule of thumb, if a consensus change does not have an associated BIP which thoroughly explains the details on a technical level that someone else can implement it, then the change is rejected. Secondly, it must be implemented as a fork with deployment parameters. This means that when the software is released, the changes are not active. Miners will signal acceptance and enforcement of the change (usually through block version numbers) and once the signalling has passed a certain threshold, the software will automatically switch to the new rules.

If signalling for the fork remains below the threshold, then it will not activate. After some point, there is an expiration. Once the expiration passes, the fork can be considered dead and removed from the code. In this case, it means that everyone has agreed that the consensus change is not necessary.

There is no BIP requiring that forks require signalling, and there is no actual vote (signalling is not a vote). However, since the very first official soft fork (Satoshi did stuff back in the day that could have caused a fork but did not because the community was still small) was BIP 34. Ever since, all forks (consensus changes) have required deployment. The current deployment system is BIP 9 VersionBits.

If there is a flaw, then the release can be retracted and miners advised to not signal for it. The fixes can be made and a new version released. However, these are generally unlikely given that most majorly accepted consensus changes are tested and reviewed for months before being accepted. They are tested on the Bitcoin testnet to ensure that there will be no problems once deployed onto the mainnet.

Not necessarily. Wladimir is not the only person with commit access. There are a lot of areas of the code for which he does not have expertise in, and he relies on other contributors to evaluate the code and recommend it for merging. There have been several Pull Requests merged where Wladimir had no comment and merged after several ACKs, and others where he had no comment and the change was merged by someone else. I'm pretty sure that he has also NACK'ed things that still got merged.

He's not the only person who is NACK'ing those proposals. Almost everybody that is part of the Bitcoin organization on Github (not all are committers) have been rejecting those proposals.

At this point, I don't think there is much that can be done through Core. You can use a tool like PyWallet (https://bitcointalk.org/index.php?topic=34028.0) to get as many of the private keys as you can from the wallet. Then take those private keys and import them to a new wallet. One caveat though, pywallet has not been updated in a while so it may not fully work with your wallet. You can contact the author of pywallet, JackJack (https://bitcointalk.org/index.php?action=profile;u=21053) if you need help with it as he has been more active recently.

The github repository for Bitcoin Core is https://github.com/bitcoin/bitcoin. Even though Bitcoin Core is the current reference client, not all changes made to it affect consensus. In fact, almost none of the changes made actually affect consensus. Rather the changes to consensus are first drafted into a BIP, discussed by many developers, implemented, reviewed, tested, and then merged into the code. This process can take a very long time, and usually a lot of changes are made to the proposal.

Consensus changes can cause forks, so in order for everyone to be using the same consensus rules, fork deployment rules for each set of changes are set in place. Some things can be added without requiring everyone to upgrade. These are known as soft forks. Other things require everyone to upgrade or they will no longer be connected to the network; those are called hard forks.

Once deployment parameters are set, the code is further reviewed and then released as another version for people to install. If people want whatever changes were made, they will upgrade to the new versions. If they don't, then they don't have to. In this way, all consensus changes are decentralized. There is no one person or central authority dictating that certain changes must be accepted. The changes are simply released, and if people want to use it, they will upgrade. Otherwise, nothing happens.

Try adding -salvagewallet to the command. You should really get your Bitcoin out of that wallet ASAP.

The options are a little hidden because they are technically debug options (i.e. you really shouldn't be using this in production). There are two options you need to set, -limitancestorcount=<n> and -limitdescendantcount=<n> where <n> is the maximum number of unconfirmed transactions in a chain that you want. If your transactions are large or you are making large chains, you will also need to set -limitdescendantsize=<n> and -limitancestorsize==<n> where <n> is the maximum total size of unconfirmed transactions in chain that you want.

I think he's hibernating for the winter  

But actually though, he did mention something about being tired of the forum.

You are talking about blockchain.info. Blockchain.info is not the same as the Bitcoin blockchain, which is what he is talking about. They are two very different things. Blockchain.info is a service, not the blockchian.

Yes.

So long as the amount that you are sending requires multiple outputs, then yes, the outputs will be consolidated.

It will always ask about the high fee until you send. In order to consolidate, you must send, and thus you must pay the fee.

Decrease the amount you are sending.

This is not just limited to blockchain.info. This happens to all wallets because of how Bitcoin works. If you make a large transaction (typically ones with many inputs), you will end up paying a high fee. It is generally better to consolidate your Bitcoin periodically so that you do not have an obscenely large transaction when you actually want to spend money. Note that outputs are not addresses. Receiving all of your Bitcoin in one address will not make a difference.

Unfortunately Blockchain.info does not give you the ability to do some more advanced things, so this is more difficult to do with precision. Just send your Bitcoin to another address in your wallet. If it does not allow you, decrease the amount until it does.

The fee has nothing to do with output consolidation.

You think 896 MB is big? The blockchain (from Bitcoin Core) is over 100 GB now. Older versions of Armory used to replicate the entire blockchain, so that would be another 100 GB. Comparatively, 896 MB is small, and in fact, is too small for Armory. Armory typically takes up around 2 GB for its databases. That it is that large is not abnormal, there is simply a lot of data to deal with.

You can delete the Bitcoin folder if your blockchain is on an external drive.