Bitcoin Transaction Stuck? Here's Why and What You Can Do

Do most mining pools support CPFP? /r/Bitcoin

Do most mining pools support CPFP? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Possibly scammed, need any technical advice please! :)

Hi bitcoin!Situation:
I am a professional poker player and ventured deep into the abyss of shady/dodgy sites. Why I did so is still a mystery to me. Long story short, I finally made two withdrawals totaling approximately $3,500 to $4,000 via BTC. Next day, I load up my Ledger and see I have my balance. Awesome!
Oh's not spendable.Surely it just hasn't confirmed yet, right? No big deal.
Then I look at the transactions...
Previous withdrawals were sent to me with a more normalized fee structure.These were sent with what looks like a near-zero fee.
With my limited technical understanding of BTC, this means the transaction will either get stuck for a VERY long time, or it will never confirm and eventually be returned to him.This person has blocked me on socials and has said on the discord server for the site that "the site is better off without him"
(Basically as a good professional player he didn't want me beating his small community of players)
I'm ok with this as long as I don't get scammed.
Is there anything I can do at this point?

Edit #1: Thanks a ton to u/jcoinner for the extensive help with spending the unspent coins via CPFP (child pays for parent) The transaction appears to be confirmed!
Using CPFP has successfully spent the unconfirmed coins back to a different wallet of mine.
The txid is: 6d65c98ea01bad8d98045794729b7d1b93936a11faad0e3bd126e9223d2ee297
and appears to show a confirm and my coins are spendable.
I believe this persons' intention was
"Send a transaction that's very likely to fail and if it does I'll scam and if it doesn't...oh well."

Thank you so much reddit!

submitted by toast4breakfastSB to Bitcoin [link] [comments]

The mempool chained transaction limit is a DISASTER for driving adoption. We need to fix this ASAP! It is one of the biggest adoption hinderances for BCH!

The mempool chained transaction limit is a DISASTER for driving adoption. We need to fix this ASAP! It is one of the biggest adoption hinderances for BCH! submitted by MemoryDealers to btc [link] [comments]

Technical Introduction to Bitcoin - Assorted Topics

I've been writing educational twitter threads on technical topics related to Bitcoin. Figured I'd share them here too for anyone whose interested.
Learn you some:
- Hash Functions
- Bitcoin Mining
- Anatomy of a Transaction
- Transaction Fees
- Consolidation Transactions
- Difficulty Adjustment
- Internet Censorship and Bitcoin
- Private Keys, Public Keys, Digital Signatures
- Bitcoin Addresses
- Child Pays for Parent (CPFP)
- Replace By Fee (RBF)
- Dollar, Debt, Inflation, and the Fed
- VPNs
- Bitcoin Seed Phrases
- Tor and the Dark Web
- Hot vs Cold Wallets
- Bitcoin Satellites
- Details of a 51% Attack
More to come!
submitted by deezydeezy to Bitcoin [link] [comments]

Flood & Loot: A Systemic Attack On The Lightning Network

u/RiccardoMasutti posted something about the Flood & Loot attack the other day on Bitcoin. I wanted to start a discussion about it.
TLDR, it seems like the attacker would essentially open up lots of channels with potential victims, would initiate transactions for as much money as possible through those victims to their own node, and then would refuse to cooperate with the final completion of the transactions with its victims, forcing its victims to post the HTLCs on chain. With enough victim HTLCs, victims would not all be able to get their transactions mined and some fraction could then be stolen by the attacker.
One aspect I don't quite understand is the number of HTLCs. The article describing the attack seems to indicate that each victim will have to publish many HTLCs onchain in order to close their channel when the attacker refuses to complete the lightning transaction. However, I was under the impression that only one HTLC would be needed per channel in such a case - even when there are many outstanding transactions being routed through them. Is that not the case?
Also, the two advantages the attacker has over the victim is the ability to set their own fee according to the fee environment at the time of the attack and the ability to use replace-by-fee. However, this seems to be quite a small advantage when considering that an attacker victim could use CPFP to expedite any channel closure transaction.
What do people think about this kind of attack?
submitted by fresheneesz to BitcoinDiscussion [link] [comments]

You can call you a Bitcoiner if you know/can explain these terms...

10 Minutes
10,000 BTC Pizza
2016 Blocks
21 Million
210,000 Blocks
51% Attack
Asic Boost
Bitcoin Cash
Bitcoin Improvement Proposal (BIP)
Bitcoin SV
Block height
Block reward
Bloom Filter
Brain Wallet
Change Address
Child pays for parent (CPFP)
Coinbase (not the exchange)
Coinmarketcap (CMC)
Colored Coin
Custodial Wallet
Craig Wright
David Kleinman
Difficulty adjustment
Difficulty Target
Dorian Nakamoto
Double spend
Elliptic Curve Digital Signature Algorithm (ECDSA)
Full Node
Gavin Andresen
Genesis Block
Getting goxed
Hard Fork
Hardware Wallet
Hierarchical Deterministic (HD) Wallet
Hot Wallet
Initial Coin Offering (ICO)
Initial Exchange Offering (IEO)
Light Node
Master Private Key
Master Public Key
Master Seed
Merkle Tree
Mining Farm
Mining Pool
Not your keys,...
Orphan block
Paper Wallet
Pieter Wuille
Private key
Proof of Stake (PoS)
Proof of Work (PoW)
Public key
Replace by Fee (RBF)
Roger Ver
Satoshi Nakamoto
Schnorr Signatures
Segregated Witness (Segwit)
Simplified Payment Verification (SPV)
Smart Contract
Soft Fork
Transaction Fees
TransactionId (Txid)
User Activated Soft Fork (UASF)
Wallet Import Format (WIF)
Watch-Only Address
List obviously not complete. Suggestions appreciated.
submitted by PolaT1x to Bitcoin [link] [comments]

Be warned- ledger nano s 'transaction accelerator' just estimated 280k satoshis/byte ($7k fees)

If I wasn't paying attention I would have lost $7k.
And the only reason I was using the accelerator in the first place is because in my original transaction, the ledger had used fees of 9 satoshis per byte (I selected medium).
So first fees are far too low, then far too high.
Paging u/btchip
I have already submitted this to ledger support email.
EDIT: it was actually 208k satoshis/byte not 280k but this doesn't make much difference. $7k was accurate.
submitted by PumpkinFeet to Bitcoin [link] [comments]

Transaction unconfirmed for over an hour

The btc i sent has a .0005 Miner fee which is supposedly high. My Satochi/byte says 59.9 is this too low? I cannot increase the fees for some reason. Using Electrum
submitted by WindowsPsycho to Bitcoin [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]

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]

Can someone explain CPFP (child pays for parent) please

I've received a bitcoin tx that is unconfirmed for close to two days now. The fee was much too small, so I understand why it's stuck.
Can someone explain how CPFP works and how I would use this as a receiver?
submitted by fishfanstan to Bitcoin [link] [comments]

Groestlcoin June Development Update & Release!

Another Quarter, Another Release! The Groestlcoin production factory has been working overtime as always in order to deliver even more tech to push Groestlcoin mainstream when the time comes.
There have been many new fantastic wallets and exchanges added to Groestlcoins repertoire over the past 3 months so we will re-cap these before moving on to what is new today.


What's New

Re-forged: Groestlcoin Samourai

Groestlcoin Samourai is a wallet for the streets. A modern Groestlcoin wallet hand-forged to keep your transactions private, your identity masked, and your funds secure. Its main advantages are its extreme portability and is the most secure Groestlcoin mobile HD wallet.
We've built a wallet that Groestlcoin deserves. If you are looking for a wallet that Silicon Valley will never build, the regulators will never allow, and the VC's will never invest in, this is the perfect wallet for you.
![Groestlcoin Samourai Release Video](

Head over to the Groestlcoin Samourai Release Page here for the full release announcement.

New: GroestlImage

Groestlimage turns any file into a mnemonic phrase allowing users to generate Groestlcoin private keys and addresses based on the data URI of the provided file. A picture is worth a thousand Groestls.



Source Code

New: Groestlcoin Core Config Generator

Groestlcoin Core Config Generator is a simple GUI to configure the groestlcoin.conf file – A developers dream tool!
Each configuration option is available via the user interface, grouped by what attributes they affect. For ease of getting started with a new configuration, a variety of preset "node classes" are available on the right-hand-side of the screen. Selecting a preset will load our recommended base configuration for a node fitting that description, at which point you can then tune the configuration at the single option level.



Source Code

New: Groestlcoin Dumb Block Explorer

Dumb Block Explorer is a trivial block explorer written in a single PHP file. Now everybody can run their own block explorer.



Source Code

New: Groestlcoin SMS Push TX

Groestlcoin Simple Push TX is a server to push Groestlcoin transactions via SMS. Now everybody can send new transactions via SMS if the Internet is not usable (i.e. blocked by government entities or becomes otherwise unavailable).


Source Code

Update: Electrum-GRS 3.3.6

Electrum-GRS is Groestlcoins #1 thin-client for Windows, MacOS, Linux and Android, based on a client-server protocol. Supporting multi-sig wallets without the bloat of downloading the entire blockchain.

New Features (Universal)

New Features (Windows, MacOS, Linux)

New Features (Android)


Source Code
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

18 hours and waiting - What did I do wrong?

EDIT Thank you all for you input, it was very helpful! I understand the fee system/mempool/CPFP/RBF/etc. much better now and have since been able to send transactions considerably faster than the 28.5 hours this one took! Really appreciate the help!
TL;DR - Where did I go wrong with this transaction? It's been 18hrs with 0 confirmations despite showing high priority:
I dabbled with mining bitcoins for fun a couple of years back and then kind of forgot about it. It came up in conversation recently so I decided to use the small amount I made back then try out cloud mining.
After hours of getting everything setup again (using Armory) I placed the order and sent the bitcoins through from my Armory wallet. 18 hours later and the transaction is yet to be confirmed despite showing as high priority. Other similar value, similar fee transactions have been confirmed
I've done a bunch of reading online and it appears that things are more complicated now than they used to be despite nothing really changing. Satoshi's were not a thing when I first started mining, nor do I remember having to be concerned about the bytes/fee ratio.
Anyway, from my reading most issues seem to come from:
I was wondering if because my coins were confirmed so far back in the chain and I've been inactive since that this might be slowing things down?
Just asking for a bit of advice really to understand why it would be taking this long and how to prevent it in future (higher fee?)
submitted by Longsh07 to Bitcoin [link] [comments]

Discussion: optimization of mempool fee levels

I'd like to discuss a possible change to the bitcoin core wallet that does not impact consensus rules.
Right now bitcoin core nodes are still the vast majority and over 60% are recent versions of bitcoin core (>16.3)
Say the mempool is like this:
mempool 2 weeks ago
What we can see from this visualisation of the mempool is that there are 5.3 MB of transactions that span from 1 sat per byte to 40 satoshi per byte (we will leave extremely expensive transactions (red color) aside for a second).
That means that we could compress all those transactions into just 6 fee levels:
5 MB with fees from 1 to 5 satoshi per byte
0.3 MB with fees of 6 satoshi per byte.
Instead of 40 satoshy per byte!!
We can achieve this by having bitcoin full nodes not creating or including in their mempool:
transactions that pay more than 1 extra sat/b when compared to the other transactions in the node mempool unless there are already enough tx to fill at least 1block (4000 KWU)
When including transactions in their mempool the nodes would basically start from those paying 1 sat per byte and include those, then move to those paying 2 sat per byte.
After that the nodes would check if there are enough transactions that pay 2 sat/b to fill 1 block (4000KWU). If true then it starts to include the transactions that pay 3 sat/b, if not it stop until there are.
In general I think this would make sure that the mempool grows in a gradual way, without any holes in it like those you can see in the image at 8 sat per bytes where there are very very few transactions.
One possible downside of this is if you have to create an expensive cpfp TX. For this situations you can unlock in your wallet the option to do this, but the default option should be to have this possibility disabled.
The power of a default setting and the incentive that, if the majority of wallets implement this “best practice”, the prices of the mining fees become rational and optimized should hopefully enough to push people to implement something like this in any wallet.
I know and understand that mining fees need to exist and I think that it is right to develop a fee market. But at the same time we should encourage the users of the wallets to not overpay for their tx to get fast confirmations because, not only do they not gain anything personally by doing that, but they also could create a spiral in the price of the mining fees that can damage Bitcoin.
In some ways it is similar to batching. No one can stop a big exchange if they want to send millions of single transactions to each of their customers when they buy or sell. Coinbase did that for quite some time.
But eventually it should become a best practice to batch transactions to minimize the footprint on the bitcoin ecosystem.
Exactly the same for this proposal.
No one can stop you to use your own wallet that let you create a tx that pays double the fees of everyone else and get into the next block. But you could’ve been included anyways by paying just 1 more sat/b than the highest fee level. And by doing that you also don’t make it more expensive for everyone else.
submitted by S3ton to u/S3ton [link] [comments]

History Lesson for new VIA Viacoin Investors

Viacoin is an open source cryptocurrency project, based on the Bitcoin blockchain. Publicly introduced on the crypto market in mid 2014, Viacoin integrates decentralized asset transaction on the blockchain, reaching speeds that have never seen before on cryptocurrencies. This Scrypt based, Proof of Work coin was created to try contrast Bitcoin’s structural problems, mainly the congested blockchain delays that inhibit microtransaction as this currency transitions from digital money to a gold-like, mean of solid value storage. Bitcoin Core developers Peter Todd and Btc have been working on this currency and ameliorated it until they was able to reach a lightning fast speed of 24 second per block. These incredible speeds are just one of the features that come with the implementation of Lightning Network, and and make Bitcoin slow transactions a thing of the past. To achieve such a dramatic improvement in performance, the developers modified Viacoin so that its OP_RETURN has been extended to 80 bytes, reducing tx and bloat sizes, overcoming multi signature hacks; the integration of ECDSA optimized C library allowed this coin to reach significant speedup for raw signature validation, making it perform up to 5 times better. This will mean easy adoption by merchants and vendors, which won’t have to worry anymore with long times between the payment and its approval. Todd role as Chief Scientist and Advisor has been proven the right choice for this coin, thanks to his focus on Tree Chains, a ground breaking feature that will fix the main problems revolving around Bitcoin, such as scalability issues and the troubles for the Viacoin miners to keep a reputation on the blockchain in a decentralized mining environment. Thanks to Todd’s expertise in sidechains, the future of this crypto currency will see the implementation of an alternative blockchain that is not linear. According to the developer, the chains are too unregulated when it comes to trying to establish a strong connection between the operations happening on one chain and what happens elsewhere. Merged mining, scalability and safety are at risk and tackling these problems is mandatory in order to create a new, disruptive crypto technology. Tree Chains are going to be the basis for a broader use and a series of protocols that are going to allow users and developers to use Viacoin’s blockchain not just to mine and store coins, but just like other new crypto currencies to allow the creation of secure, decentralized consensus systems living on the blockchain The commander role on this BIP9 compatible coin’s development team has now been taken by a programmer from the Netherlands called Romano, which has a great fan base in the cryptocurrency community thanks to his progressive views on the future of the world of cryptos. He’s in strong favor of SegWit, and considers soft forks on the chain not to be a problem but an opportunity: according to him it will provide an easy method to enable scripting upgrades and the implementation of other features that the market has been looking for, such as peer to peer layers for compact block relay. Segregation Witness allows increased capacity, ends transactions malleability, makes scripting upgradeable, and reduces UTXO set. Because of these reasons, Viacoin Core 0.13 is already SegWit ready and is awaiting for signaling.
Together with implementation of SegWit, Romano has recently been working on finalizing the implementation of merged mining, something that has never been done with altcoins. Merged mining allows users to mine more than one block chain at the same time, this means that every hash the miner does contributes to the total hash rate of all currencies, and as a result they are all more secure. This release pre-announcement resulted in a market spike, showing how interested the market is in the inclusion of these features in the coin core and blockchain. The developer has been introducing several of these features, ranging from a Hierarchical Deterministic key (HD key) generation that allows all Viacoin users to backup their wallets, to a compact block relay, which decreases block propagation times on the peer to peer network; this creates a healthier network and a better baseline relay security margin. Viacoin’s support for relative locktime allows users and miners to time-lock a transaction, this means that a new transaction will be prevented until a relative time change is achieved with a new OP code, OP_CHECKSEQUENCEVERITY, which allows the execution of a script based on the age of the amount that is being spent. Support for Child-Pays-For-Parent procedures in Viacoin has been successfully enabled, CPFP will alleviate the problem of transactions that stuck for a long period in the unconfirmed limbo, either because of network bottlenecks or lack of funds to pay the fee. Thanks to this method, an algorithm will selects transactions based on federate inclusive unconfirmed ancestor transaction; this means that a low fee transaction will be more likely to get picked up by miners if another transaction with an higher fee that speeds its output gets relayed. Several optimizations have been implemented in the blockchain to allow its scaling to proceed freely, ranging from pruning of the chain itsel to save disk space, to optimizing memory use thanks to mempool transaction filtering. UTXO cache has also been optimization, further allowing for significant faster transaction times. Anonymity of transaction has been ameliorated, thanks to increased TOR support by the development team. This feature will help keep this crypto currency secure and the identity of who works on it safe; this has been proven essential, especially considering how Viacoin’s future is right now focused on segwit and lightning network . Onion technology used in TOR has also been included in the routing of transactions, rapid payments and instant transaction on bi directional payment channels in total anonymity. Payments Viacoin’s anonymity is one of the main items of this year’s roadmap, and by the end of 2017 we’ll be able to see Viacoin’s latest secure payment technology, called Styx, implemented on its blockchain. This unlinkable anonymous atomic payment hub combines off-the-blockchain cryptographic computations, thanks to Viacoin’s scriptin functionalities, and makes use of security RSA assumptions, ROM and Elliptic Curve digital signature Algorithm; this will allow participants to make fast, anonymous transfer funds with zero knowledge contingent payment proof. Wallets already offer strong privacy, thanks to transactions being broadcasted once only; this increases anonymity, since it can’t be used to link IPs and TXs. In the future of this coin we’ll also see hardware wallets support reaching 100%, with Trezor and Nano ledger support. These small, key-chain devices connect to the user’s computer to store their private keys and sign transactions in a safe environment. Including Viacoin in these wallets is a smart move, because they are targeted towards people that are outside of hardcore cryptocurrency users circle and guarantees exposure to this currency. The more casual users hear of this coin, the faster they’re going to adopt it, being sure of it’s safety and reliability. In last October, Viacoin price has seen a strong decline, probably linked to one big online retailer building a decentralized crypto stock exchange based on the Counterparty protocol. As usual with crypto currencties, it’s easy to misunderstand the market fluctuations and assume that a temporary underperforming coin is a sign of lack of strength. The change in the development team certainly helped with Viacoin losing value, but by watching the coin graphs it’s easy to see how this momentary change in price is turning out to be just one of those gentle chart dips that precede a sky rocketing surge in price. Romano is working hard on features and focusing on their implementation, keeping his head low rather than pushing on strong marketing like other alt coins are doing. All this investment on ground breaking properties, most of which are unique to this coin, means that Viacoin is one of those well kept secret in the market. Minimal order books and lack of large investors offering liquidity also help keep this coin in a low-key position, something that is changing as support for larger books is growing. As soon as the market notices this coin and investments go up, we are going to see a rapid surge in the market price, around the 10000 mark by the beginning of January 2018 or late February. Instead of focusing on a public ICO like every altcoin, which means a sudden spike in price followed by inclusion on new exchanges that will dry up volume, this crypto coin is growing slowly under the radar while it’s being well tested and boxes on the roadmap get checked off, one after the other. Romano is constantly working on it and the community around this coin knows, such a strong pack of followers is a feature that no other alt currency has and it’s what will bring it back to the top of the coin market in the near future. His attitude towards miners that are opposed to SegWit is another strong feature to add to Viacoin, especially because of what he thinks of F2Pool and Bitmain’s politics towards soft forks. The Chinese mining groups seem scared that once alternative crypto coins switch to it they’re going to lose leveraging power for what concerns Bitcoin’s future and won’t be able to speculate on the mining and trading market as much as they have been doing in the past, especially for what concerns the marketing market.
It’s refreshing to see such dedication and releases being pushed at a constant manner, the only way to have structural changes in how crypto currencies work can only happen when the accent is put on development and not on just trying to convince the market. This strategy is less flashy and makes sure the road is ready for the inevitable increase in the userbase. It’s always difficult to forecast the future, especially when it concerns alternative coins when Bitcoin is raising so fast. A long term strategy suggestion would be to get around 1BTC worth of this cryptocoin as soon as possible and just hold on it: thanks to the features that are being rolled in as within 6 months there is going to be an easy gain to be made in the order of 5 to 10 times the initial investment. Using the recent market dip will make sure that the returns are maximized. What makes Viacoin an excellent opportunity right now is that the price is low and designed to rise fast, as its Lightning Network features become more mainstream. Lightning Network is secure, instant payment that aren’t going to be held back by confirmation bottlenecks, a blockchain capable to scale to the billions of transactions mark, extremely low fees that do not inhibit micropayments and cross-chain atomic swap that allow transaction across blockchain without the need of a third party custodians. These features mean that the future of this coin is going to be bright, and the the dip in price that started just a while ago is going to end soon as the market prepares for the first of August, when when the SegWit drama will affect all crypto markets. The overall trend of viacoin is bullish with a constant uptrend more media attention is expected , when news about the soft fork will spread beyond the inner circle of crypto aficionados and leak in the mainstream finance news networks. Solid coins like Viacoin, with a clear policy towards SegWit, will offer the guarantees that the market will be looking for in times of doubt. INVESTMENT REVIEW Investment Rating :- A+
submitted by alex61688 to viacoin [link] [comments]

Why can't there be Add-To-Fee (ATF) instead of Replace-By-Fee (RBF)?

RBF simply put is a way to replace a transaction with a higher fee so that it can be accepted by the network. It's taking the first transaction and removing it, and replacing it with a new transaction with a new fee (breaking the original tx (0 confirms)).
Why are we replacing the transaction in order to push it through with a higher fee? I'm not a core dev, but honest question here, why can't there be an add-to-fee option instead of replace-by-fee option?
Add-To-Fee could be where the original tx is still valid but the sender could addon to the original tx-fee and simply rebroadcast it so the network could pick it up again with the higher fee. Does this sound possible or is it silly talk?
A fun thing to think about it is also the acronym ATF is also a great name because it's the ATF, and we can observe the name Carl Mark FORCE by forcing a transaction with a higher fee. :)
submitted by Gobitcoin to btc [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]

Interesting discussion going on right now on Lightning Network and why it maybe has an unexpected and simple attack vector

There is an interesting discussion going on over bitcoinmarkets. Here is the full post that got a lot of attention on an unexpected attack vector:
tl;dr: Bot creates 150,000 LN channels and uses them "normally." Bot closes 150,000 LN channels quickly. Bot profits 3,000,000 with relatively low risk. Lightning Network users lose 6,000,000 or so in 48 hours. Numbers fudged but the concept holds for nearly all cases.
Alright, here I go. This is more like ELI20 than ELI5. For completeness I'm going to use the "penalty" version of the attack. I'm going to assume each block will fit 2,000 transactions, and use an average locktime of 200 to keep the numbers manageable, but bigger doesn't change the problem (much). I'm also going to assume that blocks are normally 75% full, and that 10% of unrelated transactions are willing to outbid almost anything for inclusion in the next block. Lastly, I'm going to assume that the victims respond to the attack very quickly and rationally, using a combination of fee prediction algorithms and human guesswork/panic. In reality it will be much, much worse than this because they won't act so quickly, nor will the algorithms adapt so quickly; Some users may not react at all until it is far too late and the panic is likely to spread beyond the affected users to unrelated users, increasing the damage.
Attacker opens N channels, where N is > 200 * 2000 per the above. Due to lightning's flaws, these channels are all originally balanced 100% on their side, so they have to make it so they can pay themselves, which is remarkably not-easy because it is difficult to get paid at all as a new LN user. The main purpose of this is simply to set things up so they can control the flow back and forth through intermediaries, where the destination and source are both them, and eventually flip every channel's state against their partners. Using these N channels, they transfer money to themselves through the lightning network until each channel has a "full" value historical state and then transfer it back so that the current state is "empty" from their side. Assuming 5% reserve requirement on each side (which makes LN much less efficient the higher this is), that's 5%:95% and 95%:5% (Them : Partner). This means when the attack begins, the channels actually performing the attack are all nearly empty; The actual BTC is sitting on other channels that are well-behaved and have nothing at risk, or else it is already removed from the LN. They sort the channels by size and start with the smallest channels. Starting at T=0, the first block beginning to include their attack transactions. An attacker always rebroadcasts the same number of new channels that were confirmed in the last block, and the attacker attempts to always keep their transactions as the top 1,500 highest fee paying transactions using RBF or CPFP. Victims play nearly optimally in their own self-interest; they broadcast immediately after the attacker confirms. To explain this better, I'm going to post a spreadsheet that tracks all the numbers and explain it as it goes. Here's the sheet:
In this sheet you can ignore the "profitable channels" column for the moment, it is used later, as are the columns near it. The Mempool columns track the number of pending transactions.
To simplify this process, I've made one assumption that wouldn't be true in the real world - That if a victim doesn't get mined in the very next block, they don't use RBF to pop back at the top of the fee markets. This assumption wouldn't be true in the real world, but as we'll see it makes almost no difference for the losses the victims will suffer, though it would theoretically reduce the profits the attacker makes(victims funds go to miners' fees). As we'll see, he has plenty of profits to spare, and unfortunately I can't think of an easy way to approximate this more accurately.
Due to #4 and 5 above, the only numbers that get adjusted in the spreadsheet as events play out is: #1 - The confirms the attacker gets, #2 - The confirms the victims get, and #3 - The percentage of the channel value going towards miners fees in the attacker's scenario.
I've approximated that the fees rise extremely rapidly due to the attack; Within 60 blocks, about 10 hours, the fees are already so high that the channels being attacked are worthless to almost everyone until after the attack ends. If the fees rose slower, the attacker would profit more. For convenient numbers I've used a low average channel value of 0.01 BTC(~80), and am mentally imagining the range of channel values to be in the 50-150 range.
Here are the events:
T=1-10, fees are low and predictable. Attacker is able to capture top 1,500 high fee spots while paying low fees. Victims get few confirms, only 100 per block. T=10-20, fees are rising as the fee estimation algorithms kick in. Attacker captures high fee spots by raising fees quickly. Victims raise fees and get more confirms, 200 per block meaning less "normal" confirms, aka unrelated transactions. T=20-40, fees rising quickly. Victims are capturing all of the remaining fee slots they can, given the 10% high-fee normal transactions. T=41, 42 - 6.7 hours in, the attack has been noticed and word spreads quickly. Humans jump in and start raising fees quickly to try to get confirmed, losing more and more to fees. The attacker tries to keep up but gets mostly outbid for two blocks. T=43-50 - Attacker has raised fees to 60% now and the smallest channels are priced out; Attacker begins to use some larger channels and is paying 60% of the channel value in fees to get confirmed quickly. Attacker resumes majority confirmations. T=50-60 - The attacker begins to exhaust his highest-value channels, giving up more and more of the profit to keep other users priced out. Users still can't get confirmed and realize they are facing a 100% loss if the attack continues. High fees cause a slight decrease in the normal transaction broadcast volume, but they are low value transactions so this doesn't change anything. T=61 - The attacker has exhausted his highest value channels; Fees are now more valuable than every channel he's closed or intends to attack. Any users attempting to close now take a 100% loss or more. The attacker switches to broadcasting zero-profit channels to keep the victims from getting any confirmations, taking a 5% loss on each, and costing each victim 95% in fees if they attempt to counter. T=62-71 - Normal blockspace competition has risen above even the zero-profit level for the attacker, so no broadcasting is done until his highest ones begin confirming again. T=71-100 - A few of the attacker's broadcasts confirm. Almost no victims confirm due to the high fees. T=100-200 - As the normal mempools begin to clear, more and more of the attacker's transactions confirm. He broadcasts new ones to pick up the slack and keep users priced out. A few more victims get confirmed over time as his high-value channels remaining are used up, pricing some victims back in(barely, still over 90% loss). T=201 - The attacker begins to profit due to closed transactions that have timed out. At this point, the attacker has been "punished" 34,875 times at 5% of channel value each for a total of about 17.5 BTC. He makes that back within two blocks.
Stopping to re-explain the "profitable channels" column, that's just used to keep track of how many channels the attacker opened the previous block that victims couldn't close. One block it is negative, meaning the victims closed more than the attacker could open, number 41. That multiplies by the average size to get profit, and then fee % is subtracted from that interval, all computed when those LN channels fail to hit their timelocks. This is the number that would be lower in reality, but I haven't thought of a good way to simulate users using RBF to pop at the top in time, which some(but not many) would do. If they tried to RBF to pop at the top after block 60(10 hours) they would take a >100% loss on the channel.
From 201 to 260 his profit rises rapidly, even after accounting for the high percentages he spent in fees. When he hits block 260, which was 200 blocks after he began the zero-profit broadcasts, he stops the attack. The rest of the penalty transactions need to confirm. I sped up his confirmations and the victim's slightly to get the total without going another 200 blocks to clear the mempools, but you can see how bad the mempools got during this 48 hour attack.
After all is said and done, the attacker has a revenue of 441.5 BTC after fees, and losses of 37.2 BTC in penalties. An even larger amount of BTC was likely lost by users due to miners' fees, as they could not have known the attack would end at block 260, and algorithms would likely overpredict fees for some time.
A tidy profit of 404.3 BTC for screwing with 150,000 80 channels. Or in today's dollars, 3 million profit on 12 million capital put into the attack.
That's so awful I kind of wonder if I screwed up the math. Is it really anywhere near that profitable to attack LN?? I'm sure someone will correct me if I've made a mistake; Apologies in advance.
Edit: A helpful specific example of how this scenario is set up:
Edit2: Tried some new settings, still profitable. I'm really interested to see what it takes for this to become unprofitable.
full discussion:
submitted by Kingkongkhan to nanocurrency [link] [comments]

Remember that you can use CPFP or RBF to get your transactions confirmed faster.

All three solutions below, attempt to solve the same problem, the issue of stuck transactions.
Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have created a malformed transaction (for example, accidentally setting 0 fees) that isn't acceptable or mine-able for various reasons, and it's desirable for them to be able to reissue a fixed transaction.
This is exacerbated by the undefined memory pool behavior of nodes with respect to expiring out old transactions, and not having a clear rule as to when it's safe to attempt another spend.
1) Child-Pays-For-Parent (CPFP)
The Child-Pays-For-Parent approach allows the fees of a transaction's child (the transaction that spends the outputs of the stuck transaction) to also pay for the parent transaction. This allows a merchant to spend the "broken" transaction they received like any other transaction, and the system should return to a consistent state.
The benefit of Child-Pays-For-Parent is that it solves the problem in a way that doesn't fundamentally change the mechanics for how a transaction is selected and kept (most notably, the first-seen memory pool behavior). In my opinion, this makes this solution the most intuitive.
However, the difficulty with Child-Pays-For-Parent is in the implementation. There are some required changes to the propagation of transactions that are required to make this work properly (since just broadcasting a valid child will cause other nodes to consider the transaction as orphaned, without the context of the parent).
2) Replace-By-Fee (RBF)
Replace-by-fee attempts to address the problem by changing the fundamental rule for accepting and keeping transactions, the "first-seen" rule.
In this system, a transaction with higher fees can spend already spent inputs (that have not yet been confirmed in a block), and will replace that transaction in the memory pool.
The benefit of this system is that it changes the fundamental transaction selection rule but does not require changes to the way fees are calculated.
The downside is that this represents a significant shift in terms of expected memory pool behavior. In my opinion, this makes transactions less predictable; the first-seen rule is straightforward, predictable, and easy to understand and implement. Additionally, it breaks any functionality that relies on the predictability of unconfirmed transactions by making it trivial to issue double spends. (Double spending a first seen transaction requires a combination of moderate network and computing resources, some decent know-how, and some luck. Double spending in a replace-by-fee world requires none of the above.)
3) First-Seen-Safe Replace-By-Fee (FSS RBF)
This one attempts to make RBF compatible with first-seen memory pool implementations by requiring that the outputs from the original transaction be maintained by subsequent respends.
The benefits are that in some situations, first-seen behavior can be relied upon. A transaction sending x BTC to a merchant cannot revoke that.
In practice, however, this protection is pretty weak. It trivially breaks transactions that spend other unconfirmed transactions by allowing the first transaction in the chain to be replaced, invalidating future outputs. This means that the burden for double spending an unconfirmed transaction becomes only slightly higher than in standard replace-by-fee.
It does, theoretically, allow one to accept an unconfirmed transaction that spends a confirmed output with similar protections as the typical first-seen behavior.
It is impossible to talk about this without touching on the politics, though. The reason this is so contentious is that it involves a political change that breaks many systems that rely on first-seen memory pool behavior. The proponents of the change believe that since unconfirmed transactions are not subject to the same cryptographic protections as confirmed transactions, they should be pushed out of the ecosystem and tools that facilitate this should be adopted. The people who oppose this change believe that unconfirmed transactions represent an acceptable risk as with everything in Bitcoin (remember, Bitcoin requires a majority of honest miners, for example), and that breaking something many people rely on unnecessarily is a net negative.
EDIT: More info on this sticky
submitted by PrimeParticle to Bitcoin [link] [comments]

Long-term mining incentives | Thomas Voegtlin | May 11 2015

Thomas Voegtlin on May 11 2015:
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

TXs weren't confirmed for 2 weeks now, and will probably never will. What are my options as of today?

I'm using Bitcoin Core as my wallet, and I have two unconfirmed transactions in it that were first broadcasted to the network on the 4th of December, two weeks ago.
The problem with these transactions ifs that the miner fee that was set for them, was set mistakenly to 1 Satoshi per Byte, which means that according to the current TX traffic these TXs could possibly never be mined.
I read a lot about things I can do, but the problem is that a lot of the information online is outdated and not match the current Bitcoin version.
I understand that the methods that could solve my case are:
  1. CPFP
  2. RBF
  3. Double Spend
But I also understand that some pools doesn't support some of these methods since they're not implemented in their Bitcoin version.
Considering the fact that:
  1. The two unconfirmed TXs emptied my wallet (I sent out all the BTC I had to two addresses and now my balance is 0.00...0)
  2. I am willing to decrease the amount sent in one of the TXs by 0.01 to be used as miner fee (0.005 BTC for a TX is very reasonable if I understand the current network status)
What is my best bet on getting these TXs confirmed ASAP? It's been 2 weeks+ since I was supposed to send the coins and the receiving side, although being patient and understanding, is getting upset (for a reason).
submitted by HypercatalecticTansy to Bitcoin [link] [comments]

Extension block proposal by Jeffrey et al | Luke Dashjr | Apr 04 2017

Luke Dashjr on Apr 04 2017:
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but in light
of public interest, I think it is appropriate to open it to discussion, and
toward this end, I have reviewed the current revision.
For reference, the WIP proposal itself is here: 
==Overall analysis & comparison==
This is a relatively complicated proposal, creating a lot of additional
technical debt and complexity in comparison to both BIP 141 and hardforks. It
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to
consider at face value. In fact, it fits much better the inaccurate criticisms
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is for
the most part technically sound. While ill-fit to merely making blocks larger,
it may be an ideal fit for fundamentally different block designs such as
Rootstock and MimbleWimble in absence of decentralised non-integrated
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin
==Fundamental problem==
Extension blocks are a risk of creating two classes of "full nodes": those
which verify the full block (and are therefore truly full nodes), and those
which only verify the "base" block. However, because the extension is
consensus-critical, the latter are in fact not full nodes at all, and are left
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is
of course true of a softfork as well, but softforks are intentionally designed
such that all nodes are capable of trivially upgrading, and there is no
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, but
without the false expectation and pointless complexity.
==Other problems & questions==
These outpoints may not be spent inside the mempool (they must be redeemed
from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is
required for CPFP).
The extension block's transaction count is not cryptographically committed-to
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to
exploit in practice; however, exploiting it in an extension block may not be
as impractical, and it should be fixed given the opportunity.)
The merkle root is to be calculated as a merkle tree with all extension
block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txids
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and
wtxid trees built independently and merged at the tip?
Output script code aside from witness programs, p2pkh or p2sh is considered
invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other
various possible destinations. (While static address forms do not exist for
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create
unprovably-unspendable UTXOs. Is that intentional?
The maximum extension size should be intentionally high.
This has the same "attacks can do more damage than ordinary benefit" issue as
BIP141, but even more extreme since it is planned to be used for future size
Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.
What is a "point"? What does it mean multiplied by a factor of 8? Why not just
say "8 points"?
Witness script hash v0 shall be worth the number of accurately counted
sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static counting,
or accurately counting sigops during execution?
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0
==Trivial & process==
BIPs must be in MediaWiki format, not Markdown. They should be submitted for
discussion to the bitcoin-dev mailing list, not social media and news.
Layer: Consensus (soft-fork)
Extension blocks are more of a hard-fork IMO.
License: Public Domain
BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Can you agree on one or more of these?


This specification defines a method of increasing bitcoin transaction
throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.


Bitcoin retargetting ensures that the time in between mined blocks will be
roughly 10 minutes. It is not possible to change this rule. There has been
great debate regarding other ways of increasing transaction throughput, with
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.
Extension blocks leverage several features of BIP141, BIP143, and BIP144 for
transaction opt-in, serialization, verification, and network services, and as
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally
incompatible with this one, so saying BIP 141 is activated is confusingly
This specification should be considered an extension and modification to
these BIPs. Extension blocks are not compatible with BIP141 in its current
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn’t appear to be
any justification for not making them compatible.
This specification prescribes a way of fooling non-upgraded nodes into
believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposal,
albeit in a mostly compatible manner.
Note that canonical blocks containing entering outputs MUST contain an
extension block commitment (all zeroes if nothing is present in the extension
Please explain why in Rationale.
Coinbase outputs MUST NOT contain witness programs, as they cannot be
sweeped by the resolution transaction due to previously existing consensus
Seems like an annoying technical debt. I wonder if it can be avoided.
The genesis resolution transaction MAY also include a 1-100 byte pushdata in
the first input script, allowing the miner of the genesis resolution to add a
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt with
no apparent purpose. Better to just have a consensus rule every input must be
The resolution transaction's version MUST be set to the uint32 max (`232 -
Transaction versions are signed, so I assume this is actually simply -1.
(While signed transaction versions seemed silly to me, using it for special
cases like this actually makes sense.)

Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not
the extblock's txid.
On the policy layer, transaction fees may be calculated by transaction cost
as well as additional size/legacy-sigops added to the canonical block due to
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of
doubt:" to be clear that miners may perform any fee logic they like.
Transactions within the extended transaction vector MAY include a witness
vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't this
be mandatory?
consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the
economy has updated to support segwit-native addresses.
To reduce the chance of having redeem scripts which simply allow for garbage
data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Please explain why 73 bytes in Rationale.
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
How so? Please explain.
A consensus dust threshold is now enforced within the extension block.
If the second highest transaction version bit (30th bit) is set to to 1
within an extension block transaction, an extra 700-bytes is reserved on the
transaction space used up in the block.
Why wouldn't users set this on all transactions?
default_witness_commitment has been renamed to
default_extension_commitment and includes the extension block commitment
default_witness_commitment was never part of the GBT spec. At least describe
what this new key is.
Should be just extblk if backward compatibility is supported (and !extblk
when not).
The "deactivation" deployment'...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Best Bitcoin Mining Site  Without Investment  Payment ... Raspberry Pi 4 Bitcoin Mining For 24 Hours! - YouTube How To Get Your Bitcoin Transaction Confirmed with CPFP ... Bitcoin Q&A: The mining process Best Bitcoin Mining Software That Work in 2020 🍓 - YouTube

CPFP utilizes the change in a Bitcoin transaction. Basically, if a Bitcoin transaction is stuck, then another transaction can be sent with the change from the transaction. The original stuck Bitcoin transaction is called the parent, and the new transaction using the change is called the child. A receiver can solve stuck transactions using CPFP as well. Bitcoin Transaction Accelerators. Since not all miners accept Opt-In RBF and CPFP, these options may sometimes be ineffective. Bitcoin transaction accelerators are quite effective in fast-tracking transactions even when low fees are attached. Bitcoin CPFP Experience – Child Pays for Parent. If you have ever been in a position where you were stuck waiting for days on a Bitcoin transaction to confirm because the sender did not pay a high enough transaction fee, then you understand the importance of the Bitcoin CPFP feature that has been implemented. The Bitcoin CPFP feature, or Child Pays for Parent is a feature which allows the ... Coinbase announced on 2 October 2018 that it is using Child Pays for Parent (CPFP) to push through Bitcoin transactions that get “stuck” due to fee volatility. Bitcoin transactions sent right before fees suddenly rise often get pushed down the queue in favor of transactions with higher fees; CPFP solves this issue, drastically improving the user experience. CPFP (Child Pays For Parent) This is a proposed method of 'unsticking' transactions with small fees that have difficulty getting included into a block. One of the TxOut for a transaction (which we will call "transaction P") will be the sender's address for receiving change, so you can create a new transaction (which we will call "transaction C") that has the TxIn for this TxOut.

[index] [3330] [284] [769] [5202] [2772] [5044] [3215] [5558] [2084] [1725]

Best Bitcoin Mining Site Without Investment Payment ...

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 ... 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. -------------------------------------------------------------------------------- Download: -------------------------------... 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. Buy Raspberry Pi 4 Model B 4GB: How to Setup a Raspberry Pi 4 Bitcoin Mining Rig w/ Bitmain AntMiner U3: