Bitcoin Forum
April 27, 2024, 12:42:17 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 »
161  Bitcoin / Bitcoin Technical Support / MOVED: Delete Private Keys on: April 06, 2017, 12:57:05 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1857669.0

Duplicate thread
162  Bitcoin / Development & Technical Discussion / MOVED: Elastic Securities: a regenerative supply measurement of encrypted currencies on: April 05, 2017, 09:27:16 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1856990.0

Duplicate. Wrong forum anyways.
163  Bitcoin / Bitcoin Technical Support / MOVED: i cant seem to set my gridseed bitcoin miner up at all on: April 03, 2017, 09:23:21 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1854071.0

Duplicate thread. Original here: https://bitcointalk.org/index.php?topic=1853420.msg18438180#msg18438180
164  Bitcoin / Bitcoin Technical Support / MOVED: cant unlock my funds when i lost my password but have my seed on: April 02, 2017, 07:51:52 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1852483.0

Duplicate
165  Bitcoin / Armory / Armory's position on hard forks on: March 28, 2017, 07:56:28 PM
Today we published a post on the Armory website outlining Armory's position on hard forks and what to do if BU forks. You can read the full post here: https://btcarmory.com/armory-and-hard-forks/
166  Bitcoin / Armory / Fixing the "transaction timed out"/"transaction broadcast failed" issue on: March 28, 2017, 07:52:10 PM
Update: 0.96.0 has been released. Update to that if you are still experiencing this problem.




Many of you may have noticed that with the Armory 0.95.1 and Bitcoin Core 0.14.0, Armory tends to fail to broadcast transactions and give the "Transaction timed out" and "Transaction broadcast failed" error messages.

The underlying issue that is causing this problem has been fixed for Armory 0.96, which will be released soon. However, in the meantime, downgrading to Bitcoin Core 0.13.2 will fix the issue. Once 0.96 is released, you will be able to use Bitcoin Core 0.14.0 again.

To downgrade to Bitcoin Core 0.13.2, just download the Bitcoin Core 0.13.2 binaries from https://bitcoin.org/bin/bitcoin-core-0.13.2/ and install them as you would normally install a new version of Bitcoin Core. There is no need to redownload the blockchain nor reindex Bitcoin Core's databases nor rebuild Armory's databases.




Now for the technical details about the problem, for those of you who care.

I first noticed this issue back in December, but only very recently have I nailed down why this problem cropped up in the first place.

Bitcoin Core 0.14.0 merged a change back in December which changed how Bitcoin P2P messages were being broadcast. Previously, the p2p message header and the message payload were sent all at the same time using the same kernel call. However, during their net refactor and cleanup, this mechanism was changed to send the message header in one call, and then the payload in a separate call. This is more robust and allows for better code separation, but it also causes problems for Armory.

The implementation in Armory 0.95.1 for receiving the p2p messages is not able to handle that the two parts of a p2p message are essentially sent separately. It interprets the message header as one p2p message, and the message payload as another p2p message. This means that it is incorrectly parsing the messages. The crux of the issue is that every so often Armory will receive a ping message from Bitcoin Core. However the payload of the ping message is only 8 bytes, but the message header must be 24 bytes. When Armory interprets the ping payload as a separate message, it will throw an exception because it thinks the message is too short. This exception causes the data processing thread to exit and disconnect from Bitcoin Core. Once it disconnects, it will typically reconnect, but the reconnect does not always mean that it will actually be receiving new blocks and transactions and actually remaining up-to-date with the blockchain. Thus, because of this disconnect, when you go to send some Bitcoin, it will fail to either connect to Bitcoin Core or the reconnected connection is messed up and the transaction broadcast times out or just fails entirely.
167  Bitcoin / Wallet software / MOVED: Can someone tell me where i find my private key in Bither? on: March 28, 2017, 02:26:40 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1845004.0

Duplicate
168  Bitcoin / Development & Technical Discussion / MOVED: Distribution on: March 27, 2017, 12:51:26 AM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1842094.0

Duplicate
169  Bitcoin / Development & Technical Discussion / MOVED: You can now permanently sign, store and verify any file in less than 30 seconds! on: March 25, 2017, 07:19:52 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1842107.0

Duplicate topic
170  Bitcoin / Bitcoin Technical Support / MOVED: Transaction stuck? on: March 23, 2017, 05:01:14 AM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1837414.0

Duplicate of https://bitcointalk.org/index.php?topic=1837395.0
171  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:22:28 AM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1837403.0

Duplicate of https://bitcointalk.org/index.php?topic=1837395.0
172  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:17:33 AM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1837399.0

Duplicate of https://bitcointalk.org/index.php?topic=1837403.0
173  Bitcoin / Bitcoin Technical Support / MOVED: Bitcoin transaction stuck on: March 23, 2017, 02:17:24 AM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1837401.0

Duplicate of https://bitcointalk.org/index.php?topic=1837403.0
174  Bitcoin / Bitcoin Technical Support / MOVED: Transcations has been deleted or purned from blockchain db on: March 15, 2017, 11:20:34 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1828442.0
Duplicate.
175  Bitcoin / Bitcoin Technical Support / MOVED: stuck transaction with 0.0002 fee on: March 13, 2017, 09:16:12 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1825329.0

Duplicate
176  Bitcoin / Bitcoin Technical Support / MOVED: Obligation of miners to return excessive fees on: March 10, 2017, 04:34:58 PM
This topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=1820786.0

Split from original topic:https://bitcointalk.org/index.php?topic=1818791.0
177  Bitcoin / Development & Technical Discussion / MOVED: Best bitcoin hardware wallet? on: March 08, 2017, 01:44:15 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1816673.0

Contained Referral link. Reflinks are not allowed.
178  Bitcoin / Bitcoin Technical Support / All about "stuck" transactions and what you can do to fix them on: February 23, 2017, 08:50:24 PM
What is a "Stuck" transaction? How are they caused?

A "stuck" transaction is a transaction which has remained unconfirmed for period of time which either the receiver or the sender is uncomfortable with. Stuck transactions can be annoying as it means that recipients often consider the senders to not have paid yet, or the recipient needs the money as soon as possible.

Stuck transactions are typically caused by low transaction fee rates. However other things can cause stuck transactions such as spending from an unconfirmed transaction, having dust outputs in the transaction, or being a double spend of another transaction. If a transaction has a double spending transaction and the double spend confirms, then the transaction will be "stuck" forever as it can never confirm.

What can I do to make my stuck transaction confirm?

There are a few options for confirming stuck transactions.

For both the recipient and the sender of the transaction, you can:
  • Wait for the transaction to confirm
  • Wait for the network to "forget" about the transaction
  • Ask a miner to confirm it for you

For the sender of a transaction, you can also:
  • Attempt an Replace-By-Fee double spend transaction
  • If you have a change output, you can attempt a Child-Pays-For-Parent transaction

For the recipient of a transaction, you can also:
  • Attempt a Child-Pays-For-Parent transaction

Waiting for a confirmation


If you are incapable of performing any of the other options are are too afraid to do so, you can simply wait and hope that the transaction will eventually confirm. To make sure that network is constantly being reminded of the transaction, you can rebroadcast the transaction periodically. Most wallets will rebroadcast automatically, so simply leaving your wallet open will allow rebroadcasting to happen.

Waiting for the network to "forget" about the transaction

If a transaction remains unconfirmed for too long, it can be eventually "forgotten" by most nodes on the Bitcoin network if no one rebroadcasts the transaction. This happens due to node restarts, mempool expiry times, or mempool eviction because the minimum relay fee has increased. This process typically takes a few days (usually 3). Once a transaction has been "forgotten", you may not see it in your wallet and you probably will not see the transaction in most block explorers. Once the transaction has been "forgotten", you can simply send the Bitcoin again but include a higher transaction fee. If you still see the transaction in your wallet, you will need to follow the instructions in the next Replace-By-Fee Section.

Note that some wallets will continuously rebroadcast the transaction while the wallet is on, so you either have to remove the transaction from the wallet using the instructions in the RBF section, or shut down the wallet and keep it off for several days.


Ask a miner for help


Some mining pools and miners offer services to allow you to prioritize your transaction in their mempool so that it is chosen sooner for inclusion in a block. The mining pools F2Pool and ViaBTC both offer transaction acceleration for an additional out-of-band fee. Please visit their linked websites for more details.

The blockchain explorer https://mempool.space/ also offers a transaction acceleration service as they have connections with several mining pools. You will find an "Accelerate" button next to the transaction fee on any unconfirmed transaction. This can be used to pay out-of-band for the transaction to be mined in a block sooner.

Also note that if you attempt an Replace-By-Fee transaction, both the original transaction and the RBF transaction will be considered double spends and miners will likely not help with any transactions marked as double spends.

Attempting a Replace-By-Fee (RBF) double spend transaction

What is an RBF transaction

A Replace-By-Fee transaction is a transaction that is nearly identical to your stuck transaction but pays a higher transaction fee. Since the original transaction most likely does not use Opt-in RBF, the RBF transaction that we will be creating will be considered a double spend and marked as such. The transaction uses Full-RBF and thus may still take a little bit longer to confirm as it is technically a double spend.

The difference between the types of RBF transactions

Replace-By-Fee transactions have 3 different types, First-Seen-Safe(FSS) RBF, Full RBF, and Opt-in RBF. FSS RBF requires that the RBF transaction include the same outputs as the transaction it replaces and consumes the same inputs. Full RBF means that the transaction is simply a double spend of another transaction but pays a higher transaction fee than the one(s) it replaces. Opt-in RBF means that the RBF transaction can only replace a transaction that has Opted-in to allowing itself to be replaced. Opt-in RBF follows BIP 125.

The instructions given in this section will be for making Full RBF transactions. Opt-in RBF transactions will be described in the "Avoiding Stuck Transactions In The Future" section.

How to make a Full RBF transaction

Making a Full RBF transaction depends entirely on the wallet that you are using. Some wallet support the advanced functionality required to make a Full RBF transaction, others do not. The following will be guides for each wallet on how to make a Full RBF transaction with that wallet. In general the procedure is to remove the unconfirmed transaction from the wallet and then resend the Bitcoin but with a higher transaction fee.

When making a Full RBF transaction, the transaction should include the recommended fee rate at the time of creating the transaction. See the "Avoiding this issue in the future" section for help with that.

Bitcoin Core

Bitcoin Core makes making Full RBF transactions very easy. Simply go to the transactions list, right click the transaction that is stuck, and choose the "Abandon Transaction" option.

If that option is greyed out, then you must go to the Bitcoin Core datadir and delete the mempool.dat file. Then restart Bitcoin Core with the -walletbroadcast=0 option and then you should be able to use "Abandon Transaction".

Once the transaction is either Abandoned or cleared from the wallet, you can simply go to the Send tab and send the Bitcoin again but make sure that you include a sufficient transaction fee.

Bitcoin Armory

Bitcoin Armory also makes making Full RBF transactions very easy. Go to Help > Clear All Unconfirmed Transactions and restart Armory. This will clear all of the unconfirmed transactions from the wallet and thus allow you to create the Full RBF transaction. Once Armory has restarted, simply send the Bitcoin again as you normally would but be sure to include a sufficient transaction fee.

MultiBit HD

MultiBit HD allows for making Full RBF transactions fairly easy as well. Go to Manage Wallet and click on Repair Wallet and follow the wizard. This process will clear all of the unconfirmed transactions from your wallet much like Bitcoin Core and Armory do. Once repair wallet has completed, simply send the Bitcoin again as you normally would.

Wallets that do not allow you to or ones that I don't know how to make Full RBF transactions

Not all wallets support the creation of Full RBF transactions. Many wallets do not allow clearing all unconfirmed transactions to allow for making Full RBF transactions. The following is a list of wallet software which do not support Full RBF transactions. If a wallet on this list does support FullRBF transactions, please let me know and provide instructions for that so I can add it above.

  • Blockchain.info and web wallets in general
  • Electrum (supports Opt-in RBF, but not Full RBF)
  • Mycelium
  • MultiBit Classic
  • Bitcoin Wallet for Android
  • Breadwallet
  • Copay

Attempting a Child-Pays-For-Parent transaction

What is a Child-Pays-For-Parent transaction?


A Child-Pays-For-Parent (CPFP) transaction is exactly as the name implies, a child transaction spends from an unconfirmed parent transaction and includes a transaction fee which covers both the fee of the child and the parent. However creating CPFP transactions are much more difficult as it requires spending from an unconfirmed transaction, something that most wallets do not allow.

How can I avoid making Stuck transactions in the future?

Using Dynamic Fees

The best way to avoid having stuck transactions is to make sure that you are not spending from an unconfirmed transaction, and include a sufficient transaction fee. If your wallet supports dynamic transaction fees, you should use those. If you want very fast confirmations, set the dynamic fees to choose the fastest fee possible. Dynamic fees are calculated by the wallet by analyzing the current state of the network and determining an optimal transaction fee from there. Because the state of the network constantly changes, the optimal transaction fee calculated one day may not necessarily be the best fee for the next day.

If your wallet does not support dynamic fees but does support setting a custom transaction fee rate for each transaction, you can look up the optimal fee rate on sites like https://mempool.space/ and https://bitcoinfees.github.io/ and set the fee rate for each transaction based on those sites. You must do this for each transaction you make otherwise you may end up paying a sub-optimal fee.

If your wallet does not support any sort of fee rate or does not allow setting custom transaction fees, you should upgrade to a new wallet. Using a fixed fee or fixed fee rate is no longer a good idea as the network constantly changes. You can use this formula: <in>*148 + <out>*34 + 10 where <in> is the number of inputs and <out> is the number of outputs to estimate the size of your transaction and determine the optimal fee for it.

Note that some wallets (e.g. blockchain.info), even though they use dynamic fees, set an upper limit to the transaction fee. If you notice that your transactions are constantly being stuck even though you are using dynamic fees, you should check the settings of your wallet and perhaps even switch to a new wallet which has no limit to the transaction fee.

Use Opt-In RBF

Opt-In RBF is a feature that allows for an RBF transaction to be more easily created as these transactions will not be rejected by nodes supporting Opt-In RBF.

Currently several wallets support creating Opt-In RBF transactions, many by default.

Bitcoin Core

Opt-in-RBF is enabled by default, but can also be enabled or disabled on a per-transaction basis. On the "Send" tab, clicking on "Choose..." next to the transaction fee field will give access to the "Enable Replace-By-Fee" checkbox. Checking this will enable Opt-in RBF for the transaction, although it should already be checked by default.

Unconfirmed transactions that have opted in to RBF can have their fee increased by right clicking the transaction in the "Transactions" tab and choosing the "Increase transaction fee" option.

Electrum

Electrum always creates transactions with Opt-in RBF enabled.

To increase the fee of a transaction that uses Opt-In RBF, right click the transaction in the history list and choose the "Increase Fee" option.

Armory

Armory also allows for the creation of RBF transactions. When sending a transaction, choose the checkbox "Enable RBF".

To increase the fee of a transaction that uses Opt-In RBF, right click the transaction in the transactions list and choose the "Bump Fee" option. Transactions whose fee can be increased are labeled clearly in the transactions list.



This post is meant as a more thorough update to https://bitcointalk.org/index.php?topic=232979.0.

If there are any inaccuracies or if I am missing anything, please let me know and I can add it. If anyone has instructions for CPFP or RBF with any wallets, please let me know and give me the detailed instructions so I can add them to the post.
179  Bitcoin / Bitcoin Technical Support / MOVED: i can't send money on: February 08, 2017, 02:02:37 PM
This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=1782225.0

Duplicate thread
180  Bitcoin / Development & Technical Discussion / List of people who have had commit access to Bitcoin Core on: February 01, 2017, 10:19:06 PM
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
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!