Topic: Bitcoin Master guide (Read 1270 times)

Hey guys,

I've updated the article after following through.

I'm sticking with the "Bitcoin Limbo" expression, as I feel that it completely captures the transactions that seem to struggle to get confirmed by the network (for whatever reason)

I've paid attention to the various details you mentioned especially for the misleading sentences and I think I've eradicated most of the misleading data. Have a look at it and let me know if I've missed something!

The link is the same: https://www.crypto-news.net/transactions/

Hey DannyHamilton and Franky1,

Nice to see you guys participating in the creation of this guide. It would be really hard to create something accurate without the help of veterans such as yourself. Once again, I would like to thank you for your time and effort to generate these responses. I will analyze what you've told me and recreate the article to better explain, and not mislead readers.

Just want to get it out there, as you can see I'm not an old member of this community, so I'm relying on you to be as active and brutally honest as you are. I have to admit feeling frustrated at how much I've gotten wrong, but that's the fun in the creation process.

With your help, I am learning a lot of details about Bitcoin and eventually, many other people will.

I will post once more a little bit later, once I've updated the article to eliminate misleading sentences and information.

agreeing with danny that ultimately there is a 0.5%-2% BLOCKS get orphans.
but to clarify
so those tx's in that block do return to being unconfirmed which is a temporary issue because sooner or later they are added to a new accepted block.

however there is a
example of where transactions are not added to the next block could be causes such as
plus other factors

so the ultimate worry(in regards to transactions) is alot less than 2% and far less than 0.5%(these numbers are about blocks, not tx's). and more so in the 0.004% risk area.  not ever getting confirmed.

---

also agreeing with danny..
in a normal no drama day (no new soft/hard fork event activation or high orphan rate)
6 is usually the maximum.

the only possibly time to think about waiting 2 hours (12 blocks+) would be when something controversial (high orphan count) is occuring, which is usually only a once every couple year event, so it should not be wrote as if its a normal expectation.. to think about daily...
 but maybe wrote as a sidenote to people to expand the confirms they usually wait for if the blockchain is in the middle of a hard/soft feature upgrade that appears to be controversial on the activation day

kind of like saying..
you dont need to boil your water every to want a drink, but if you have precious children you could wait for the water to boil if you worry about their health. but maybe when there are some water pipes being replaced in the water network every couple years, then get more concerned about doubling your efforts

---

Why do you say:
"The optimal fee value is 0.0000001 BTC per Byte"?

Why is that amount optimal?  Optimal in what way?  Is it the cheapest fee possible?  Is it the fee that will result in the fastest confirmation?  Is it the fee that gives the best balance between cost and confirmation time?  Does it change with time, or is it always that amount?

That is only 10 satoshi per byte. It seems like a REALLY small fee, and would likely result in VERY LONG confirmation times.

---

You also say:
"Each and every Bitcoin wallet out there is equipped with the tools you need to facilitate transactions"

But, I think some wallets don't provide you with the tools you need to set an appropriate fee.  With those wallets, you are relying on the wallet to choose a proper fee for you, and some of them don't.

---

It also might be good to distinguish between "wallets" (such as blockchain.info, Bitcoin Core, Electrum, MultiBit, etc) and "accounts" (such as Coinbase, localbitcoins, BitStamp, etc).

---

Your phrase:
"the “transaction memory pool” of the network"

Makes it sound like the entire network shares a single memory pool.  In reality each peer has its own memory pool.  Each peer can potentially have their own rules about which transactions are accepted into their memory pool and how long the transactions stay there.  Different peers can have different transactions in their memory pool.

---

The following is not true:
"Nodes pack transactions together to form 1Mb blocks"

Nodes relay transactions to other nodes and maintain their own memory pool and their own copy of the blockchain.  They do NOT pack transactions together into blocks.  Solo miners and mining pools pack transactions together into blocks.

---

Regarding following:
"When miners create a valid POW hash, these are combined and transmitted across the network where every node needs to validate it."

You are now getting into details about mining and the blockchain, and are no longer talking about transactions.  Every node validates every transaction before it ever relays it to any other node. This happens before the transaction has been included into a block, and before the POW has been completed.   Later, when nodes receive completed blocks, they validate the entire block before they relay the block or add the block to their own copy of the blockchain.

---

The following paragraph doesn't make any sense:
"The proper way to facilitate transactions is to create space for yourself for the duration of 3 blocks for normal transactions, at least 1 block for low-value transactions and at least 12 blocks for high-value transactions. A block takes about 10 minutes to get mined, verified and confirmed. Your transaction is making a stronger impact on the network in direct correlation to its age"

Lets look at each piece of it individually...

"The proper way to facilitate transactions is to create space for yourself for the duration of 3 blocks for normal transactions, at least 1 block for low-value transactions and"
The recipient of a transaction gets to decide how many confirmations they want before they'll consider a transaction "completed".  If you are sending a transaction and are unsure how many confirmations your recipeint will want to wait for, you should ask them.  Unconfirmed transactions are perfectly fine under the proper circumstances.  One confirmation will often be fine for the majority of recipients.  High value transactions in low-trust situations may require additional confirmations.

"at least 12 blocks for high-value transactions"
Twelve confirmations?!  That's ridiculous. I'd trust a $10 million transaction with someone I didn't trust at all with only 5 or 6 confirmations.

"A block takes about 10 minutes"
Ten minutes is the long term AVERAGE amount of time between blocks when averaged over a large enough quantity to be statistically significant. Any single block can come as quickly as 1 second, or take longer than 90 minutes.

"to get mined, verified and confirmed"
That time is spent on the mining.  The verifying only takes a few seconds on most modern computers.  Confirmed means the same thing as mined, there is no need to say it twice.

"Your transaction is making a stronger impact on the network in direct correlation to its age"

stronger impact?  The impact of a transaction doesn't change. I'm not sure what you're trying to say there.

---

How did you decide this:
"you need to ensure that you are always sending the transactions with a high-enough fee, in order to ensure that your transaction will get picked up in the first three blocks."

Why three blocks?  What if I don't want to wait for three blocks?  What if I'm willing to wait more than 3 blocks?  Why to I always need to make sure it will be within three blocks specifically?

---

Regarding this:
"also it’s going to take longer for the network to pick it up and place it in a block, thus validifying"

"The network" doesn't place it in a block. A solo miner or mining pool does.  I don't think "validifying" is a word.  Perhaps you meant to say "confirming"?

---

Regarding:
"The two other common situations are unfortunately unavoidable once they happen."

Actually, both of those situations are easily managed if you pay a high enough transaction fee.

---

"If the network is overloaded, it’s going to take some time for the transactions to finalize"

Unless you pay a higher transaction fee to provide solo miners and mining pools to include your transaction into the next block.

---

You clearly don't understand what a hard fork is:
". . . there is a debate about changing the block size for Bitcoin from 1Mb to 4Mb . . . some argue that making such a change will cause a hard fork to happen . . ."

A "hard fork" is any change that requires all nodes to agree on the new rules.  Hard forks are a good thing when they improve the protocol and usability, and when an overwhelming majority of users agree to the new rules.  Hard forks are a bad thing if they are attempted with a large minority or small majority of users supporting them.  Bringing up the concept of a "hard fork" (especially when you don't really understand it in the first place) doesn't help the user understand the process of creating a transaction.  You'd probably be best served to keep your politics out of this "master guide".

---

This is nonsense:
"Orphan blocks can cause transactions to be stuck in 'Bitcoin Limbo'"

There is no "limbo".  If the transaction is in a block in the current blockchain, then it is "Confirmed" with a number of confirmations equal to the number of blocks that have been added to the chain.  If the transaction is not in a block in the current blockchain, then it is "unconfirmed".  A transaction that was confirmed with only a few confirmations can become unconfirmed if there is a large enough chain reorganization, but it isn't "in limbo"  it is just back to being in an unconfirmed state.

---

This is misleading:
"About 0.5% to 2% of blocks in one day will get orphaned."

Since this is a disussion about transactions, it seems to imply that 0.5% to 2% of transactions per day that are confirmed will become unconfirmed.  However, if you paid a sufficient transaction fee, then it is very likely that your transaction will remain confirmed in a block in the longer chain even if it was previously confirmed in a block that was orphaned.  It is possible that some transactions from the block will become unconfirmed, but most of them wont.  Even if they are, they will most likely confirm in the next block or two.

Hey everyone,

We added a new article to our Bitcoin Master Guide. It talks about transactions, how they work, as well as common problems one can encounter when making transactions.

You can check it out here: https://www.crypto-news.net/transactions/

Let us know what you think.

Cheers,
Who_

Hey HabBear,

This is a great idea, we will inevitably end up posting the article there, as soon as we feel it's complete enough to prompt the mods to Pin it to the thread. This would be a great success and recognition for us and is something we strive to attain.


Hey Kumax,

We do plan on expanding it in due time. In the current state I understand the guide as a framework for further development, so additions as well as revisions will surely be made for it. We will keep everyone updated here.


Thanks for clearing this up for me. It's beneficial to know that the transaction data is taken care of by the network and that the miners only take care of the block headers.


There should be some sort of early-warning system to give information to users about the approximate number of confirmations they should wait for until risk is mitigated.


Hey Calkob,

It was our goal to provide answers to these newbie questions. It takes a while for a person to be fully equipped with the knowledge and a resource such as this one could provide extremely beneficial to educate people about the different parts of the ecosystem and how they all intertwine together to create Bitcoin as it is.


Hey Rrita,

Thanks for the support. It's what keeps us going!


Hey Paxful_Marketing,

Thank you for your support. If your friends take our survey it can help us understand if we've left questions unanswered for them. Cheers!


Hey Xester,

We don't mind at all. This guide was meant to be shared and used for education! Thanks for your kind words and support.


Hey Densuj,

We are indeed conducting a survey and we are asking people here to help us reach more people on reddit by upvoting our post there. The reasons we are doing this is to gather intelligence and opinions that will help us further develop the guide in the future. In the end, we would like to see our guide pinned on the top of Beginners and Help section eventually.

Thank you all for your kind words, criticism, opinions and feedback. We are open for all forms of communication and are dedicated to creating the number one informational resource to learn about Bitcoin.

I think it is more good on services discussion than to beginner and help section
because the OP talking about https://www.crypto-news.net/bitcoin-master-guide/  
the OP have made survey, taking upvote on reddit also taking opinion from other users.
 

This is very helpful to the starters in bitcoin or to the newbies or neophytes in the business. I congratulate you and at the same time thank you for doing a guide and this is very helpful for me in teaching my friends pertaining the basics on bitcoin. If you dont mind I will share your link to my friends on facebook. Goodluck and more power!

Kudos for putting in the effort to open this for opinion and corrections. I will share this with a few friends.

Nice article about bitcoin relatew topics. Thank you for sharing this article.Newbie will get help mostly by this article and they can know about bitcoin more.keep it up .

Thanks for that, these sorts of guides always come in useful and are great to give to friends when they start asking the usual noob questions.

yes the transactions are put back into the mempool.
imagine block A and block B got solved at same time..

because 2 different pools done the blocks and indepentdantly decided what their block added.. some of the same tx's would be in each other block. and some transactions may differ.. eg pool B decided to accept some fee free transactions but pool A decided to mainly look at the high price and some tx's middle priced would be in both..

lets say A got orphaned for a reason.
A puts all transactions back into mempool and then looks at B and sees whats confirmed to know which transactions to not handle in A's next attempt because B confirmed them


miners (ASICS) dont handle or see the full 1mb of data.. they just get the hash of that data and then rehash it with a nonce until it creates a new hash which meets the solution requiring a certain amount of 0's at the start of the new hash.


once an asic finds a hash solution.. it is just handed another hash (new block attempt) to start.. asics dont care about tx data. they just re-hash whatever hash they are handed.. in short asics(miners) dont validate and check transactions

if the pool gets told to orphan the full block the pool handed out to the network because of a problem. the pool then makes a new block hash based on new block data and sends the hash to the asics to start again.

what asics only see as negative is the wasted time working on something that ultimately didnt end in the network longterm, thus no pay for the wasted time.

double spends are a concern to the network because the block is sent out to the network and then thrown out if it was a bad block or a better block was preferred.

so while on the network for those couple seconds or more.. some merchants may have ticked a box to say 'yep confirmed' and released goods/services/fiat to the customer.. then 2seconds or more later.. that block is gone. but the goods/services/fiat is already handed to the customer...

usually in 99.996%-99.75% the tx they thought was confirmed sits back as unconfirmed again until included in the next block so no harm done ultimately but just waiting to reconfirm....
but
as said in previous post (on a good no drama day) in 0.004% or 0.25% chance of the tx not being added to the next block for either malicious reason or unintentionally struck off by how the network works.

(note there are other ways to mess with tx's in an orphan event. but lets not complicate things)

this small under 1% risk is lowest odds. and not strict numbers they are variable. for instance when there is a new feature being added (code rule) like the current 95% soft fork. could result in 5% orphans occurring(higher risk) and many malicious people may increase their malicious attempts ontop due to the "perfect storm to go on a riot" mindset. so it could end up being over 5% risk instead of one 2500th of 1% risk of malicious intent..  or due to the higher blocks.. less 'free transactions' get accepted so the risk of a free transaction not getting re-confirmed becomes riskier.

so its still a risk and worth waiting a few blocks
like some say 1confirm for small amounts (coffee value) 6 confirms (car/house value) during normal no drama transacting.

---

the terminology was that if there is a bad block found that has no competing better block yet. its just called a rejected/invalid block.
however if after getting the block(a1) a new block is built ontop(a2).. but later a competing block(b1)+(b2) has something preferable where the network has to orphan (a2) because (b2) was linked to a different previous block(b1), making (a1 <-the parent) get rejected thus (a2) is the orphan because it lost its parent.

though, these days we use the term 'orphan' for any block that initially had a solution but then thrown away and something else that takes its place for multiple reasons. whther the network had to reject any parents or not.

there have been times in the past where a block with SEVERAL parents(previous blocks) gets orphaned/rejected off in preference of a better chain of blocks

hense the 6confirm mindset many people have, because a chain of 5 blocks can ALL get orphaned as it has happened before.

usually during feature activation events (the day segwit or dynamic blocks reaches 95% to activate) the orphan risk is higher so some say maybe wait 10 confirms for house value amounts.

lets say there was a 51% attack or a controversial activation of a rule (very high orphan risk) some people will say wait 72-144 blocks (12-24 hours) before trusting

Thanks for the nice article! It nicely sums up bitcoin problematics and it's definitely a good choice for those, who wants to gain some knowledge about bitcoin and generally about cryptocurrencies.
It is good for beginners, but personally, I would go little deeper maybe, it's too short for getting really into it.
Maybe do you plan to extend it a bit?

Easy comment here, but not mentioned yet. Once you get this final vetting and revisions complete, make sure you post this master guide to the Beginners & Help section of this forum. It'll be mighty useful.

@Franky1

These are some quite interesting issues that you're bringing up here. As a non-technical looking for the easy way out, I suspect that the network can integrate CLTV and CSV to provide an additional layer of security to transactions. Just like paypal and credit card transactions have this "clearing period", maybe in the future every transaction will have some sort of network confirmation requirement that would unlock the funds.

On the other hand this may seem unreasonable to a lot of people, looking at Bitcoin as an instant payment system.

Future speculations aside, I do hope that developers and block explorers alike will eventually turn around to create a graphical representation of all important factors about individual transactions, promptly hidden behind an "advanced" menu that would give Bitcoiners the choice to see this information or not. (depending on how seriously they understand any particular transaction, with the assumption that seriously interested people would take the time to research and learn more about the available information attached to blocks and presented by explorers.)

I believe I will write a section about Transactions and everything one must pay attention to in order to assure that it will be picked up and placed in a block and it won't get stuck in "transaction limbo" if the particular block gets orphaned.

Question about orphans: Since they are blocks that are not part of the main chain, due to another hash getting a higher number of confirmations, does this mean that the transactions are lost, or are they placed back in the transaction pool, ready to be placed once more?

My current understanding is that miners mine the same block of transactions consisting of a Block header (80kb of hash data), Block Body (1mb of transaction data) and a nonce, which they use to reach a correct hash. This would suggest that orphaned blocks are a concern only for miners, but not for the network and its users, since the network naturally follows the longest chain and the transaction gets mined anyways. Double-spending attacks should be of no concern, since the orphaned block eventually falls off and is forever forgotten by the network.

Please evaluate my understanding written in bold above. Is it correct and spot-on? I can clearly see that it is different from what you initially say, but please realize that I am simply offering a different perspective on this theoretical situation.

I must extend gratitude once more to you Franky1, as you've been instrumental in opening up my perspective into different problems that need to be considered in future development of this guide.

@Velkro

The fact that something is difficult, does not mean that people will not try. The reality is this. Bitcoin users need a comprehensive guide that will explain in plain terms the complexity of Bitcoin and every connecting part, without compromising the truth or cutting corners.

Bitcoin Master Guide is an informational product that strives to become this comprehensive guide that the ecosystem is lacking. One of the most realistic ways that writers such as myself, which are not technical experts in the field can achieve a goal like this is to recruit the help of the community in order to eliminate errors and provide legitimate information to new people joining the cryptocurrency ecosystem.

Also, there are many definitions for the word "Master". The one we are representing is "main; principal", meaning that we are striving to be the first resource that people will use to refer their friends that are interested in Bitcoin to come to. It is true, Bitcoin is evolving, disruptive and innovative, but these pronouns can also be used to describe The Bitcoin Master Guide, as well.

We hope to bridge the gap of knowledge between developers and people just starting off. I hope that this explained our intention as to why we've begun developing this guide.

orphan risk can lead to double spend attack as you say. so you are near spot on. especially if while orphaned a mallicious spender then uses RBF to strike off the then (re-)unconfirmed tx before its put into a new block. to substitute it with another tx where the values/destinations differ
(more so the finney attack on the next paragraph after the 'race attack' you linked, but with new features like RBF which wasnt around in hal finneys time, to make it more possible to adjust transactions when an orphan occurs).

but not to try confusing the matter more.. the reason i say 'not quite', 'more so' and 'near spot on'. is that on a usual day is 1% of orphan. the risk of a finney attack is 0.0004%.. (because you only care about 1tx of the whole block. so chances is one 2500th of 1%)
there are other things..  like someone that didnt pay a fee getting into a block.. but if that block orphans it again sits as unconfirmed but may not get into another block due to no fee.. risk of this is could be 0.25% (if pools use old preference of 25% of a block has no fee, divided by orphan risk)
there are many ways that tx's cant be trusted. not just maliciously. but also unintentionally struck off by how the network works.
but now thats getting too detailed of the behind the scenes where things are no longer static but variable and confusing
 

as for CLTV and CSV
firstly while unsettled (inside LN) CLTV and CSV are not penalties. they are just terms of agreement. but when broadcast. the tx is confirmed onchain.. and the CLTV is a maturity period (like the block rewards 100 confirm waiting period 'maturity') where it cannot be spent. and the CSV is a special output that the second party can spend the intended recipients funds before the maturity expires.

so even though its confirmed on chain the intended recipient cant spend it until matured and is at risk of the other party revoking it during maturity.

this is like paypal or a bank having a 3-5 day 'clearing period' and a chargeback able to occur in that time.
so even if you see its confirmed but unspendable, lik the bank saying unavailable balance and separately available balance. dont presume your guaranteed that 'unavailable' money until its available.

im sure all the block explorers will update their graphic user interfaces to alert people if a tx contains CLTV and CSV.. but for now it has to be done manually by knowing what to look for in the raw data

Yeah because in reality there is no bitcoin masters out there. Maybe core developers (only few of them) and Andreas Antonopolous.
Everyone else, including person which wrote this article is no expert enough to write in details about such disruptive and innovative technology like bitcoin. I mean comeone, this is so high level code (bitcoin) that few people will understand ever.

Hey Franky1,

Would you like to elaborate on the risk? What exactly is at risk? Are we talking about the chance that a block is going to get orphaned, or that the sender is executing a race attack? https://en.bitcoin.it/wiki/Double-spending#Race_attack

For me, reading your feedback establishes that you are indeed talking about the risk for a double spending attack occurring in any transaction. I've made some additional changes to this section that cautions the reader to learn more about these attacks. The risk evaluation seems arbitrary to me and I would love it if you could further explain so that I could better understand and transmit the knowledge to readers down the line.

In regards to CLTV and CSV, since they are utilized to establish payment channels between multiple parties, while retaining the ability for one to send back his BTC in the absence of a signature on the transaction. What would be the main ways that an attack can be realized through the use of these features?

Also, is there an easy way for a person to check Tx maturity? How would a newbie go about to check if transaction maturity has expired?

I've changed the part of the guide that claimed 100% valid transactions into a transaction safe from an attack.

Thanks for your feedback and support. Through active members in the community, just like you, we can create a valuable resource that will satisfy the information needs of generations of Bitcoiners to come.

Edit: If you want us to remove your name from the guide, we have no choice but to comply with your request. It has been our plan from the beginning was to incorporate the community as an active force in the development of the guide. This way we are held accountable for what we write in our guide. It is our goal to create a comprehensive guide that will legitimately satisfy the needs of people interested in learning about Bitcoin.


Thanks for your kind words and support mikehersh2!

It is inevitable for this guide to get more and more complex over time, much like Bitcoin has grown over time. Especially if we have people like franky1 opting in with their technical knowledge of the network, keeping us honest.

errr..

"In order to protect your long-term interest when making Bitcoin transactions, it’s important to wait for at least six network confirmations before deciding that the transaction is 100% valid. As a rule of thumb, the security of any individual transaction is closely related to its age, with older transactions being far more resistant to change when compared to new transactions."

still not completely correct.

"In order to protect your long-term interest when making Bitcoin transactions, it’s important to wait for at least enough confirmations before deciding the risk is negligible. As a rule of thumb, the security of any individual transaction is closely related to its age, with older transactions being far more resistant to change when compared to new transactions. the risk is 1%-5% dependant events, features update periods, so 6 confirms would be advised for larger value transactions"
..
the 1-5% explains and covers the reasons for 6% and also what to do at a 95% (5% risk event)
separately..
because CLTV and CSV is an actual feature compared to previous years. its important to mention tx maturity.. especially when its going to be used alot more by the time your guide gets popular.

maybe add,
"if your transaction has been involved in a locked-in contract such as a side service like Lightning, usually the expiration of maturity occurs after more than 6 confirms. but dont trust it as valid/guaranteed until the maturity expires."

p.s
no need to name drop. just ensure if its a master guide it's not glossing over the important bits people need to know

I will definitely be sharing that page! Provides a quality but concise summary of the basic assets of Bitcoin. 99Bitcoins, a YouTube channel, also has many videos that summarize basic terms or assets of Bitcoin that is

very helpful, especially for people brand new to Bitcoin. Here is an example, https://www.youtube.com/watch?v=u5xHWQyW_lk