How to issue a CPFP? : Bitcoin

"My transaction is stuck, what to do?" - an explainer [DRAFT]

In the last days we have been experiencing a sharp rise in price, which is historically correlated with many people transacting over the Bitcoin network. Many people transacting over the Bitcoin network implies that the blockspace is in popular demand, meaning that when you send a transaction, it has to compete with other transactions for the inclusion in one of the blocks in the future. Miners are motivated by profits and transactions that pay more than other transactions are preferred when mining a new block. Although the network is working as intended (blockspace is a scarce good, subject to supply/demand dynamics, regulated purely by fees), people who are unfamiliar with it might feel worried that their transaction is “stuck” or otherwise somehow lost or “in limbo”. This post attempts to explain how the mempool works, how to optimize fees and that one does not need to worry about their funds.

TL;DR: Your funds are safe. Just be patient* and it'll be confirmed at some point. A transaction either will be confirmed or it never leaves your wallet, so there is nothing to worry about in regards to the safety of your coins.

You can see how the mempool "ebbs and flows", and lower fee tx's get confirmed in the "ebb" times (weekends, nights):,30d
* if you are in hurry there are things like RBF (Replace By Fee) and CPFC (Child Pays For Parent), which you can use to boost your transaction fees; you will need an advanced wallet like Bitcoin Core or Electrum for that though. Keep also in mind that this is not possible with any transaction (RBF requires opt in before sending, f.ex). If nothing else works and your transaction really needs a soon confirmation, you can try and contact a mining pool to ask them if they would include your transaction. Some mining pools even offer a web-interface for this: 1, 2.
Here’s how Andreas Antonopoulos describes it:
In bitcoin there is no "in transit". Transactions are atomic meaning they either happen all at once or don't happen at all. There is no situation where they "leave" one wallet and are not simultaneously and instantaneously in the destination address. Either the transaction happened or it didn't. The only time you can't see the funds is if your wallet is hiding them because it is tracking a pending transaction and doesn't want you to try and spend funds that are already being spent in another transaction. It doesn't mean the money is in limbo, it's just your wallet waiting to see the outcome. If that is the case, you just wait. Eventually the transaction will either happen or will be deleted by the network.
tl;dr: your funds are safe

How is the speed of confirmations determined in bitcoin?

Open this site:,2w
Here you see how many transactions are currently (and were historically) waiting to be confirmed, i.e how many transactions are currently competing with your transaction for blockspace (=confirmation).
You can see two important things: the differently coloured layers, each layer representing a different fee (higher layer = higher fees). You can point at a layer and see which fees (expressed in sat/byte) are represented in this layer. You can then deduct which layer your own transaction is currently at, and how far away from the top your position is (miners work through the mempool always from the top, simply because the tx's on top pay them more). You can estimate that each newly mined block removes roughly 1.xMB from the top (see the third graph which shows the mempool size in MB). On average, a new block is produced every ten minutes. But keep in mind that over time more transactions come into the mempool, so there can be periods where transactions are coming faster than transactions being “processed” by miners.
The second important observation is that the mempool "ebbs and flows", so even the lower paid transactions are periodically being confirmed at some point.
In short: what determines the speed of a confirmation is A) how high you set the fees (in sat/byte), B) how many other transactions with same or higher fees are currently competing with yours and C) how many transactions with higher paid fees will be broadcast after yours.
A) you can influence directly, B) you can observe in real time, but C) is difficult to predict. So it's always a little tricky to tell when the first confirmation happens if you set your fees low. But it's quite certain that at some point even the cheap transactions will come through.

So what happens if my transaction stays unconfirmed for days or even weeks?

Transactions are being broadcast by the full nodes on the network. Each node can adjust their settings for how long they keep unconfirmed transactions in their mempool. That’s why there is not a fixed amount of time after which a transaction is dropped from the mempool, but most nodes drop unconfirmed tx’s after two weeks [IS THIS CORRECT?]. This means that in the absolute worst case the unconfirmed transaction will simply disappear from the network, as if it never happened. Keep in mind that in those two weeks the coins never actually leave your wallet. It’s just that your wallet doesn’t show them as “available”, but you still have options like RBF and CPFP to get your transaction confirmed with higher fees, or to “cancel” your transaction by spending the same coins onto another address with a higher fee.

Helpful tools to estimate fees for future transactions:

Here are some resources that can help you estimate fees when sending a bitcoin transaction, so you don't end up overpaying (or underpaying) unnecessarily. Keep in mind that in order to take advantage of this, you need a proper bitcoin wallet which allows for custom fee setting. A selection of such wallets you can find here or here.
The order here is roughly from advanced to easy.
Here you can see a visualization of how many unconfirmed transactions are currently on the network, as well as how many were there in the past. Each coloured layer represents a different fee amount. F.ex the deep blue (lowest layer) are the 1sat/byte transactions, slightly brighter level above are the 2sat/byte transactions and so on.
The most interesting graph is the third one, which shows you the size of the current mempool in MB and the amount of transactions with different fee levels, which would compete with your transaction if you were to send it right now. This should help you estimating how high you need to set the fee (in sat/byte) in order to have it confirmed "soon". But this also should help you to see that even the 1sat/byte transactions get confirmed very regularly, especially on weekends and in the night periods, and that the spikes in the mempool are always temporary. For that you can switch to higher timeframes in the upper right corner, f.ex here is a 30 days view:,30d. You clearly can see that the mempool is cyclical and you can set a very low fee if you are not in hurry.
This is also an overview of the current mempool status, although less visual than the previous one. It shows you some important stats, like the mempool size, some basic stats of the recent blocks (tx fees, size etc). Most importantly, it makes a projection of how large you need to set your fees in sat/byte if you want your transaction to be included in the next block, or within the next two/three/four blocks. You can see this projection in the left upper corner (the blocks coloured in brown).
This is a simple estimation tool. It shows you the likelihood (in %) of a particular fee size (in sat/byte) to be confirmed within a particular timeframe (measured in hours). It is very simple to use, but the disadvantage is that it shows you estimates only for the next 24 hours. You probably will overpay by this method if your transaction is less time sensitive than that.
This is a very simple bot that tweets out fees projections every hour or so. It tells you how you need to set the fees in order to be confirmed within 1hou6hours/12hours/1day/3days/1week. Very simple to use.
Hopefully one of these tools will help you save fees for your next bitcoin transaction. Or at least help you understand that even with a very low fee setting your transaction will be confirmed sooner or later. Furthermore, I hope it makes you understand how important it is to use a wallet that allows you to set your own fees.
submitted by TheGreatMuffin to u/TheGreatMuffin [link] [comments]

Does Trezor Wallet allow you to create a transaction with unconfirmed bitcoins?

Basically, I want to know if you can easily create a CPFP transaction on the Trezor. For example, you have 10 BTC in one of your Trezor accounts. You send someone 8 and let's say you set a super low fee of 1 sat/byte. The transaction sits unconfirmed for 1 day.
But since you know there is change coming back to you. Can you make another transaction from that account and select to send the 'MAX' amount of bitcoins (hoping the bitcoin in the change address will be included) and this time you set a super high fee so that the miner will pickup both the first low-fee transaction and also the second one?
I know this can be done in theory but I am wondering if the Trezor wallet will even allow you to try to 'spend' the change since it is unconfirmed? In other words, when you select to send 'MAX' on the Trezor will it select only confirmed bitcoins and ignore the BTC that are going into the change address from the previous transaction?
submitted by bjman22 to TREZOR [link] [comments]

Interesting change allowing for "Reciever pays" TXN fees.

I'm excited about a new change in bitcoin-qt v20.0 (unreleased) allowing for the propagation of zero fee (0 sat/b) TXNs. Previously this was nerfed by the minRelayTxFee requirement. This would allow the receiver to set the fees (indirectly) by simply chaining a CPFP TXN to the end of it. Might work something like this.
  1. You place a bet at a BTC betting site.
  2. If you win, the payout is a raw TXN hex string.
  3. You broadcast the raw TXN along with a second "child" that pays the fee.
  4. Betting site is now no longer paying fees on winning bets.
Could offer a lot of solutions to exchanges that require a "withdraw fee" claiming that they need to pay the miners. This would allow users to request a zero-fee raw-hex withdraw transaction allowing the user to pay the fees themselves.
For the more technical user this would offer up a lot of neat possiblities.
submitted by brianddk to Bitcoin [link] [comments]

Rules for TXN propogation, minRelayTxFee and FeeFilter with CPFP ancestors and decedents

Looking at the default reference implementation, I'm trying to get an idea has to how minRelayFee, FeeFilterand CPFP work. So maybe someone can tell me where I'm off track.
To restate, I think each Tx must meet the requirements for minRelayTxFee, and FeeFilter on its own merits and without segwit considerations. But using segwit and CPFP may make a Tx more attractive to a miner, who is ultimately the one that matters.


Looking at TXN [2bc2f5f247cbd1ad32a90d85f4dbefd2a60ed9573fb9ea2cebd69b605e29e43c](, I'm thinking that segwit is considered in these calulations. The just use vbyte instead of WU (1/4 vbyte). But I still think CPFP is ignored.
Moved to bitcointalk:
submitted by brianddk to Bitcoin [link] [comments]

Bitcoin Price Prediction 2020

Bitcoin Price Prediction 2020
Bitcoin is a digital and fully decentralized currency. Decentralization of the network is the main goal of the Bitcoin. The fundamental achievement of bitcoin is its genuine peer-to-peer payment system; no person or even institution was “in charge” of bitcoin.
by StealthEX
Three main ideas were embedded in the Bitcoin code:
• Bitcoin should not be regulated by anyone.
• Its emission should not be infinite.
• The cost of a coin depends on its demand.
The maximum number of bitcoins – 21 million, and the possibility of their extraction were laid in the bitcoin algorithm.
Bitcoin “halving” occurred on 11 May 2020. This means that its miners’ remuneration was halved.

Bitcoin statistics

Source: CoinMarketCap, Data was taken on 19 May 2020.
Current Price $9,672.54
ROI since launch 7,048.96%
Market Cap $177,790,148,642
Market Rank #1
Circulating Supply 18,380,918 BTC
Total Supply 18,380,918 BTC

Bitcoin achievements and future plans

Bitcoin in 2019:

Bitcoin Core released:
• Improved Partially Signed Bitcoin Transaction (PSBT) support and added support for output script descriptors. This allowed it to be used with the first released version of the Hardware Wallet Interface (HWI).
• Implemented the new CPFP carve-out mempool policy, added initial support for BIP158-style compact block filters (currently RPC only), improved security by disabling protocols such as BIP37 bloom filters and BIP70 payment requests by default. It also switches GUI users to bech32 addresses by default.
LND released:
• Support for Static Channel Backups (SCBs) that help users recover any funds settled in their LN channels even if they’ve lost their recent channel state.
• Improved autopilot to help users open new channels, plus built-in compatibility with Lightning Loop for moving funds onchain without closing a channel or using a custodian.
• Added support for using a watchtower to guard your channels when you’re offline.
• Added support for a more extensible onion format, improved backup safety, and improved the watchtower support.
• Its price has more than doubled.
• For the first time in history Bitcoin was assigned a rating of “A”.
• British court recognized Bitcoin as property.
• The second largest in Germany and ninth in Europe, the Stuttgart Stock Exchange launched Bitcoin spot trading.
• In Russia, for the first time, Bitcoin was added to the authorized capital of a company.
• Bitcoin Named the Best Asset of the Decade by Bank of America Merrill Lynch.

Bitcoin in 2020:

• Focus on the Lightning Network. The continuation of work on c-lightning (Blockstream), Eclair (ACINQ), LND (Lightning Labs) and Rust Lightning to develop the protocol.
• Expectation of the SchnorTaproot softfork in 2020 or 2021 that is improvement in fungibility, privacy, scalability and functionality.
Bitcoin “halving” occurred on 11 May 2020.
• Amid the general crisis caused by coronavirus pandemic (COVID-19) and the depreciation of money, the Bitcoin value is growing.

Bitcoin Technical Analysis

Source: TradingView, Data was taken on 19 May 2020.

Bitcoin Price Prediction 2020

TradingBeasts BTC price prediction

The Bitcoin price is forecasted to reach $8,681 (-10.25%) by the beginning of June 2020. At the end of 2020 BTC price will be $8,345 (-13.72%).

Wallet investor Bitcoin price prediction

Bitcoin price prediction: maximum price by the end of December 2020 $13,559 (+40.19%), a minimum price $7,886 (-18.47%).

DigitalCoinPrice Bitcoin forecast

There will be a positive trend in the future and the BTC might be good for investing. BTC price will be equal to $22,501 at the end of 2020 (+132.63%).

Crypto-Rating BTC price forecast

Based on historical data Bitcoin price will be at $12,272 (+26.87%) in 1 week and $13,338 (+37.90%) in 1 month. Analysis of the cryptocurrency market shows that Bitcoin price may reach $18,679 (+93.11%) by the 1st of January 2021 driven by the potential interest from large institutional investors and more regulation expected in the field of digital currencies.

Buy Bitcoin at StealthEX

Bitcoin (BTC) is available for exchange on StealthEX with a low fee. Follow these easy steps:
✔ Choose the pair and the amount for your exchange. For example ETH to BTC.
✔ Press the “Start exchange” button.
✔ Provide the recipient address to which the coins will be transferred.
✔ Move your cryptocurrency for the exchange.
✔ Receive your coins.
The views and opinions expressed here are solely those of the author. Every investment and trading move involves risk. You should conduct your own research when making a decision.
Original article was posted on
submitted by Stealthex_io to u/Stealthex_io [link] [comments]

Is Bitcoin Unlimited also going to remove "RBF"? As many recall, RBF was a previous, unwanted soft-fork / vandalism from clueless "Core" dev Peter Todd, which killed zero-conf for retail - supported by the usual lies, censorship, fiat and brainwashing provided by Blockstream and r\bitcoin.

Is Peter Todd's unwanted RBF ("Replace-by-Fee") feature vandalism also finally going to be removed with Bitcoin Unlimited?
I saw this earlier post about it, but I'm not sure if this is still in effect:
"The Bitcoin Unlimited implementation excludes RBF as BU supports zero-confirmation use-cases inherent to peer-to-peer cash."
Below is a compendium of posts from last year, chronicling the whole dreary mess involving RBF.
The Bitcoin community never wanted RBF (Peter Todd's "Replace-by-Fee").
A "Core" dev (the well-known vandal/programmer Peter Todd) tried to force RBF on people, against the wishes of the community - using the usual tactics of lies, brainwashing and censorship - with support / approval from the censored r\bitcoin and the corporate fiat-funded Blockstream.
On Black Friday, with 9,000 transactions backlogged, Peter Todd (supported by Greg Maxwell) is merging a dangerous change to Core (RBF - Replace-by-Fee). RBF makes it harder for merchants to use zero-conf, and makes it easier for spammers and double-spenders to damage the network.
Peter Todd's RBF (Replace-By-Fee) goes against one of the foundational principles of Birtcoin: IRREVOCABLE CASH TRANSACTIONS. RBF is the most radical, controversial change ever proposed to Bitcoin - and it is being forced on the community with no consensus, no debate and no testing. Why?
By merging RBF over massive protests, Peter Todd / Core have openly declared war on the Bitcoin community - showing that all their talk about so-called "consensus" has been a lie. They must now follow Peter's own advice and "present themselves as a separate team with different goals."
Was there 'consensus' about RBF? I personally didn't even hear about it until about a week before it soft-forked (read: it was unilaterally released) by Core.
Consensus! JGarzik: "RBF would be anti-social on the network" / Charlie Lee, Coinbase : "RBF is irrational and harmful to Bitcoin" / Gavin: "RBF is a bad idea" / Adam Back: "Blowing up 0-confirm transactions is vandalism" / Hearn: RBF won't work and would be harmful for Bitcoin"
The blockchain is a timestamp server. Its purpose is to guarantee the valid ordering of transactions. We should question strongly anything that degrades transaction ordering, such as full mempools, RBF, etc.
Rethinking RBF and realizing how bad it actually is.
When Peter Todd previously added RBF to a pool, it was such a disaster it had to be immediately rolled back:
yeehaw4: "When F2Pool implemented RBF at the behest of Peter Todd they were forced to retract the changes within 24 hours due to the outrage in the community over the proposed changes." / pizzaface18: "Peter ... tried to push a change that will cripple some use cases of Bitcoin."
RBF needlessly confused and complicated the user experience of Bitcoin
RBF explicitly encouraged user to "double-spend", and explicitly encouraged people to repeatedly change change the receiver and amount of already-sent transactions - which obviously was supposed to be taboo in Bitcoin.
Usability Nightmare: RBF is "sort of like writing a paper check, but filling in the recipient's name and the amount in pencil so you can erase it later and change it." - rowdy_beaver
"RBF" ... or "CRCA"? Instead of calling it "RBF" (Replace-by-Fee) it might be more accurate to call it "CRCA" (Change-the-Recipient-and-Change-the-Amount). But then everyone would know just how dangerous this so-called "feature" is.
Proposed RBF slogan: "Now you can be your own PayPal / VISA and cancel your payments instantly, with no middleman!"
Peter__R on RBF: (1) Easier for scammers on Local Bitcoins (2) Merchants will be scammed, reluctant to accept Bitcoin (3) Extra work for payment processors (4) Could be the proverbial straw that broke Core's back, pushing people into XT, btcd, Unlimited and other clients that don't support RBF
RBF was totally unnecessary for Bitcoin - but Blockstream wanted it because it created a premature "fee market" and because it was necessary for their planned centralized / censorable Lightning Hub Central Banking "network"
Reminder: JGarzik already proposed a correct and clean solution for the (infrequent and unimportant) so-called "problem" of "stuck transactions", which was way simpler than Peter Todd's massively unpopular and needlessly complicated RBF: Simply allow "stuck transactions" to time-out after 72 hours.
RBF and 1 MB max blocksize go hand-in-hand: "RBF is only useful if users engage in bidding wars for scarce block space." - SillyBumWith7Stars ... "If the block size weren't lifted from 1 MB, and many more people wanted to send transactions, then RBF would be an essential feature." - slowmoon
RBF has nothing to do with fixing 'stuck' transactions
"Reliable opt-in RBF is quite necessary for Lightning" - Anduckk lets the cat out of the bag
Blockstream CEO Austin Hill lies, saying "We had nothing to do with the development of RBF" & "None of our revenue today or our future revenue plans depend or rely on small blocks." Read inside for three inconvenient truths about RBF and Blockstream's real plans, which they'll never admit to you.
Quotes show that RBF is part of Core-Blockstream's strategy to: (1) create fee markets prematurely; (2) kill practical zero-conf for retail ("turn BitPay into a big smoking crater"); (3) force users onto LN; and (4) impose On-By-Default RBF ("check a box that says Send Transaction Irreversibly")
It's a sad day when Core devs appear to understand RBF less than jstolfi. I would invite them to read his explanation of the dynamics of RBF, and tell us if they think he's right or wrong. I think he's right - and he's in line with Satoshi's vision, while Core is not.
There were several different proposed "flavors" of RBF: opt-in RBF, opt-out RBF, "full" RBF, 3-flag RBF (which includes FSS-RBF), 2-flag RBF (with no FSS-RBF)...
Of course:
  • The terminology was not clearly defined or understood, and was often used incorrectly in debates, contributing to confusion and enabling lies
  • This was another example of how Peter Todd is completely unaware of the importance of the User Experience (UX)
  • RBF supporters exploited the confusion by lying and misleading people - claiming that only the "safer" forms of RBF would be implemented - and then quietly also implementing the more "dangerous" ones.
3-flag RBF (which includes FSS-RBF) would have been safer than 2-flag RBF (with no FSS-RBF). RBF-with-no-FSS has already been user-tested - and rejected in favor of FSS-RBF. So, why did Peter Todd give us 2-flag RBF with no FSS-RBF? Another case of Core ignoring user requirements and testing?
8 months ago, many people on btc (and on bitcoin) warned that Core's real goal with RBF was to eventually introduce "Full RBF". Those people got attacked with bogus arguments like "It's only Opt-In RBF, not Full RBF." But those people were right, and once again Core is lying and hurting Bitcoin.
Now that we have Opt-In Full RBF in new core (less problematic version) Peter Todd is promoting Full RBF. That didn't take long...
So is Core seriously going to have full-RBF now ? Are the BTC businesses OK with that ?
RBF slippery slope as predicted...
Overall, RBF was unnecessary and harmful to Bitcoin.
It killed an already-working feature (zero-conf for retail); it made Bitcoin more complicated; it needlessly complicated the code and needlessly confused, divided and alienated the many people in the community; and it also upset investors.
RBF and booting mempool transactions will require more node bandwidth from the network, not less, than increasing the max block size.
RBF is a "poison pill" designed to create spam for nodes and scare away vendors.
Evidence (anecdotal?) from /BitcoinMarkets that Core / Blockstream's destructiveness (smallblocks, RBF, fee increases) is actually starting to scare away investors who are concerned about fundamentals
The whole RBF episode has been a prime example of how Blockstream and Core (and the censored forum they support: r\bitcoin) are out of touch with the needs of actual Bitcoin users.
Bitcoin Unlimited is the real Bitcoin, in line with Satoshi's vision. Meanwhile, BlockstreamCoin+RBF+SegWitAsASoftFork+LightningCentralizedHub-OfflineIOUCoin is some kind of weird unrecognizable double-spendable non-consensus-driven fiat-financed offline centralized settlement-only non-P2P "altcoin"
submitted by ydtm to btc [link] [comments]

Feerates for dependent transactions.

This link, section "Feerates for dependent transactions (child-pays-for-parent)", explains a simple algorithm for miners to maximize their revenue from transaction fees.
However, as the article points out "Except for some edge cases that are rare and rarely have a significant impact on revenue, this simple and efficient transaction sorting algorithm maximizes miner feerate revenue after factoring in transaction dependencies."
One edge case that particularly worries me is when the opposite of CPFP occurs: let's say the mempool is almost empty and I make a transaction that pays 1000 sat/B, then a child that pays 999 sat/B, then a child of the child that pays 998 sat/B, then a child of this child that pays 997 sat/B. Using the simplistic algorithm explained in the link above, all childs will be ignored for the first block. After the parent is mined, all childs except the first child (now the parent) will be ignore in turn. This will lead to the last child being confirmed much later than it should be, in a situation with almost an empty mempool.
My question is: do the current algorithms in use by miners, for choosing which transactions to be included in the next block take into account this edge case? Or they fail to maximize the miner fee in a case like this?
I could experiment and see for myself what the result is, but I hope someone has some insight into this.
submitted by johnturtle to BitcoinBeginners [link] [comments]

Gavin Andresen on Twitter: "One of the 200,000 stuck BTC txs is a payment to me. Now I have to waste part of my life trying to unstick it."

Gavin Andresen on Twitter: submitted by BobsBurgers3Bitcoin to btc [link] [comments]

Getting closer and closer to the tipping point. Around 40% blocks over the last 24 hours are signaling either BU or Classic.

submitted by 1BitcoinOrBust to btc [link] [comments]

"The Bitcoin Unlimited implementation excludes RBF as BU supports zero-confirmation use-cases inherent to peer-to-peer cash."

submitted by Egon_1 to btc [link] [comments]

TX malleability is NOT a bug. It's a feature and it already has a fix!

  1. You create a TX that pays part of its outputs to yourself and has a zero fee.
  2. You then create a child TX that gives all of its inputs to the miners as fees.
According to the fee market rules, any malleated version of the parent TX will never be confirmed because a miner would get ZERO fees. The CPFP TX guarantees that the original parent TX will be confirmed since it includes the hash of the parent TX as dictated by the sender of the funds. If the parent TX was malleated then it would lose its CPFP TX and thus the intended fees.
The most important change needed for this fix to work is that double-spending TXs are relayed across all nodes (not just BitcoinXT nodes).
Now please shut the fuck up about SegWit needed so bad for the TX malleability fix. It's utter bullshit. Also it is bullshit that double-spending TXs are not relayed. I urge all sane full node developers to start relaying 0-confirmation double-spending TXs so that businesses could ACTUALLY SEE THEM and deal with them according to the free market principles. 0-confirmation TXs would already be safe to accept if double-spending TXs were properly relayed. The TX chain that pays most in fees should always be preferred. This is the stuff BlockstreamCore does not want you to know. So go now and smear it in their face.
submitted by 1Hyena to btc [link] [comments]

Bitcoin Core IRC meeting summary (June 2, 2016)

submitted by eragmus to Bitcoin [link] [comments]

Transaction malleability solved without SegWit? Here's how.

I asked Craig Wright his opinion on the need to solve transaction malleability. He claimed there is already a solution in Bitcoin today. I followed up with other attendees and here is my understanding of how it works.
1) Create a transaction with zero fee that you must relied on to have the same transaction ID at zero confirmation and 1 confirmation.
2) create a child pays for parent transaction spending the value from step 1 and include a fee.
This gives very high assurance that your transaction from step 1 gets mined without being malleated. Because if it's malleated the miner gets no fee. Additionally, it's very unlikely for a zero fee transaction to be mined.
Bitcoin is economic. We should look for incentives that solve our problems.
submitted by pointbiz to btc [link] [comments]

ViaBTC's Transaction Accelerator Test Results

I submitted 10 transactions to ViaBTC's Transaction Accelerator (more info) as a test and all got confirmed. Tx IDs [1][2][3][4][5][6][7][8][9][10] all confirmed in block #441750.
The transactions are not my own but were from the 2015 coinwallet spam/DoS attack. The transactions were originally broadcast in October 2015 but were never confirmed. The transactions are large (~15KB each) and have a very low free (~1sat/B), so would ordinarily not be confirmed under current network conditions.
So in conclusion:
submitted by basil00 to Bitcoin [link] [comments]

Longest unconfirmed transaction?

I have been waiting almost 5 days, I sent to my coinbase account with low fee. I heard that unconfirmed tx should just clear itself from mempool after a while, but I have read that some have unconfirmed transactions from months ago (on other sites).
Does coinbase keep rebroadcasting the transaction so it won't clear from mempool? The number of unconfirmed transactions seems to constantly increase, so does this mean there are 10's of thousands of unconfirmed transaction that will be pending indefinitely?
This is more a general bitcoin question, but I posted on other subreddit but it's just full of memes.
submitted by ImOnRedditWow to CoinBase [link] [comments]

over 12 hours and no confirmation, can any one help me out.

over 12 hours and no confirmation, can any one help me out. submitted by XxEnigmaticxX to Bitcoin [link] [comments]

Is it possible to create a transaction that can have the fees paid by the recipient address?

0 fee transactions are of course an option, but risky for everyday use as a merchant. just like with merchants that accept CC payments, it is the merchant that pays the fees essentially, not the CC user. many merchants in the past did not accept credit cards due to fees, but realized they were loosing customers by not accepting credit cards, so even with fees it is still worth it to accept credit cards
would it be possible for merchants that want to be able to do this with Bitcoin with significantly less fees compared to credit cards?
besides this there must be a use for transactions that have fees paid by recipient, even if really small fees it removes barriers to entry even more and can be a selling point for merchants to spend much less on fees while advertising no-cost/free transactions
submitted by DaSpawn to btc [link] [comments]

CPFP (raising fee via child-pays-for-parent) implemented in Bitcoin Wallet.

CPFP (raising fee via child-pays-for-parent) implemented in Bitcoin Wallet. submitted by BitcoinWallet to Bitcoin [link] [comments]

Why do want RBF instead of Child Pays for Parent?

Why is it better to set RBF as the standard instead of developing a standard to give the payee an option to do a child pays for parent transaction and pay the fee to get the payment to confirm. Honestly it seems like having the payee pay the fee is a better system to me altogether.
Can someone tell me why I'm wrong?
submitted by Bitcoin_Acolyte to Bitcoin [link] [comments]

[FAQ] Why are my fees so high?

At Mycelium Support we get questions like this all the time. Here are some answers around fees:
submitted by giszmo to mycelium [link] [comments]

Can you please help explain why this transaction seems stuck

It was done at same time as 12 other transactions from electrum wallet, 6 of which have gone through without a problem. 6 seem stuck despite saying high priority. total amount for all transactions was less then the balance on the wallet so i wasnt spending btc i dont have. driving me crazy.
submitted by Mr-Evandal to Bitcoin [link] [comments]

'unconfirmed' transactions for more than 5 month now. What can I do?

I used a not-so-great app (NOW I know) to transfer some btc. The app didn't send any fees, so the transactions were left out. Yes, I am wiser now.
So I have these unconfirmed transactions waiting with the btc left nowhere. One of the transactions happend to be go to /millionmakers. The first transaction was startet 2016/06/20 (ID: d2a3337278e373380954b6853bad93f52e17cd7ace688cf9c4462d20723899bd)
When I track it, always shows a 'recieved date' from today of yesterday, following ever since.
What am I doin wrong and what can I do to get a) my coins back or b) complete the transaction so that /millionmakers gets them?
submitted by w33d to Bitcoin [link] [comments]

aantonop - YouTube bitcoin shit - YouTube Bitcoin Q&A: Iterating nonces and the block reward Bitcoin Q&A: Mining incentives after 2140 How to block Bitcoin Mining in your browser - Working 100%

Miner fees are a fee that spenders may include in any Bitcoin on-chain transaction. ... so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees. When a miner creates a block proposal, the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block ... Bitcoin’s Child Pays For Parent (CPFP) is an elementary concept which means that the child transaction is paying and compensating for the parent transaction so that both can be confirmed soon. On a lighter note, you can think of it as a parent having less money for their expenses, and that’s where their child comes to rescue to pay the difference on their behalf. Bitcoin is a distributed, worldwide, decentralized digital money. Bitcoins are issued and managed without any central authority whatsoever: there is no government, company, or bank in charge of Bitcoin. You might be interested in Bitcoin if you like cryptography, distributed peer-to-peer systems, or economics. A large percentage of Bitcoin enthusiasts are libertarians, though people of all ... Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community. Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Jobs; Unanswered ; How to issue a CPFP? Ask Question Asked 3 years, 7 months ago. Active 2 ... Bitcoin-Miner erhalten alle Transaktionsgebühren aus dem Block, den sie gewinnen. Als solches ist es also in ihrem Interesse, den Geldbetrag zu maximieren, den sie verdienen, wenn sie einen Block erstellen. Was sie also tun, ist, die 1.000.000 Bytes an Transaktionen auszuwählen die ihnen das meiste Geld einbringen. Aus der Sicht des Bitcoin-Miner ist nicht der Wert einer Transaktion ...

[index] [43125] [35473] [49846] [446] [24804] [6759] [12138] [632] [30055] [2557]

aantonop - YouTube

He is the author of two books: “Mastering Bitcoin,” published by O’Reilly Media and considered the best technical guide to bitcoin; “The Internet of Money,” a book about why bitcoin matters. What happens to Bitcoin after 2140? Will bitcoin transactions work? How will miners be incentivised without the block subsidy? What role do futures markets play? These questions are from the ... aantonop's YouTube channel is THE place to find free, unbiased educational videos on all things Bitcoin and open blockchain. Subscribe & join the channel to ... Can spam transactions be used to artificially drive up fees in Bitcoin? What is Child Pays for Parent (CPFP)? This is a question from the patron-only live Q&A which took place on February 24th 2018. New Bitcoin Generator Mining 2019 VerTef BitcoV14 (Working 100%) - Duration: 15 ... How To Get Your Bitcoin Transaction Confirmed with CPFP - Duration: 7:15. m1xolyd1an Recommended for you. 7:15 ...