image art by
As of January 2017, the number of daily transactions on the Bitcoin network have reached nearly 300,000.
Compare this to the number of Bitcoin transactions happening in 2010, the time this thread was created: 813. A lot of discussion is revolving around solving the scalability issues with Bitcoin, especially after the recent frenzy when Bitcoin went over $1,100 and some people experienced long delays with their transactions.
If you do a Google search for "unconfirmed Bitcoin transaction" you start to get an idea about the scalability issues that we are currently experiencing. Here's a common question that arises:
"For whatever reason, I have been waiting forever for my transaction to confirm. Why is it taking so long for my transaction to confirm?" -Bitcoinstackexchange
Six and a half years ago, developers in a forum were discussing this exact thing we're currently experiencing today. We can learn a lot about the origins of Steem from this discussion between Dan Larimer, co-founder of Steemit and anonymous creator of Bitcoin, Satoshi Nakamoto.
Dan said he didn't know for absolute sure if the user named satoshi on bitcointalk.org was the real Satoshi Nakamoto, but he and everyone else assumes it to be him/her/them. Correct me if I'm wrong on this point.
The question that was posed by a user named Red on the thread in Bitcointalk was as follows:
I'm curious about the developers feelings on scalability. For example, could the system handle a million users, doing say 5 transactions each per day. 5 million transactions per day is roughly 35,000 transactions per 10 minute period? Is there a bottle neck in propagating 35,000 transactions to a million nodes for block generation? Or has that issue been designed for?
Here's one of Dan's responses:
I am convinced that bandwidth, disk space, and computation time necessary to distribute and "finalize" a transaction will be prohibitively expensive for micro-payments. Consider for a second that the current banking industry is unable to provide a reasonable micropayment solution that does not involve depositing a reasonable sum and only allowing a withdraw after a reasonable sum has been accumulated.
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
Satoshi's answer:
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
Quote from: bytemaster:
"Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today."
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
Here's Dan's response:
I fully believe you and came to conclusion you did. I read the snack machine post after posting by earlier comment.
So, what's Satoshi's snack machine concept?
If you've ever wondered why someone cannot spend the same Bitcoin 2 different times, here's your answer below from Satoshi:
The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 - 0
4 - 1
16 - 4
64 - 16
80% 20%
So if a double-spend has to wait even a second, it has a huge disadvantage.
The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
The conversation between Satoshi Nakamoto and Dan from 2010 on Bitcointalk is definitely worth reading through and it leads me to the following question:
As a newbie, I do not understand the differences between the Bitcoin blockchain and the Steem blockchain.
Does Dan's Steem technology solve the scalability issue that is currently making Bitcoin transactions slow? If so, how? If this is truly the case, then it would be good to understand the fundamental differences between the Bitcoin blockchain and the Steem blockchain. If you have the answers, please add them or point me to a link. More understanding of this will help people see Steem's advantages.
If you're a newbie, and still not sure how Bitcoin actually works, watch this video. It cleared up the concept of hashrate which I didn't fully understand until now:
You just never know what I will write about next...........
thanks to 