Topic: Questions about Block! (Read 202 times)

such much is wrong with that statement

transactions are information about where funds came from and where their going to.

a confirmed transaction is when said transaction has been included in a block, and said block has gone through the mining process and majority accepted by nodes verifying theres nothing wrong with all the data.

mining is the process of using math to produce a very hard to replicate hash of the blocks initial id. making a super strong ID that takes effort/cost to undo/replicate

mining is NOT limited, because even after the 21m coins get into circulation, miners can still mine and just take a fee from existing coins rather than creating more coins, by charging a cost to those making transactions.

if there was no more mining. then transactions dont get confirmed. thus making bitcoin useless. so mining has to continue to have the ability to make transactions.

Mining and transactions are two different things. Mining is when you are solving algorithms using your hardware to catch a block. Transactions on the other hand is when you transfer an already mined bitcoin from  one address to another address. Mining is limited since there are only  21 millions bitcoin to be mined while transactions are unlimited since even if there is no more mining transactions will still continue.

the hash of the previous block, not the current block. see here: https://en.bitcoin.it/wiki/Block_hashing_algorithm


past blocks are not mutable, to the extent that proof of work secures them. this doesn't apply to blocks yet to be mined.

transactions in very simple form are like
from(amount)to(amount)signature

the signature is created using privatekey of the from

those making blocks do not make a block and put transactions into it. it is NOT a make a cardboard box then fill it... instead its collate transactions together into a batch and the batch is a block. kinda like harvest the wheat and make a haybale

you then also add the solved block hash of the previous block. thus linking blocks together into a chain
you then make a block hash for your block, in simple terms an ID that is a calculation of all the data in the batch

if you change a transaction you change the blocks ID.
if you change the transactions in previous block or change the previous blocks, the previous ID's wont match and so the one in your block wont match.

so by having the hashes shows the data is valid and not edited as it can be easily checked

then to secure it, the blocks id is sent to special equipment that hash it trillions of times until a new ID comes out of it that has to have a specific number of 0's at the start. the more zeros the harder it is for someone else to try finding the same hash ending

..
so a transaction is a simple piece of data saying where funds came from and going to and proof you have the secret password to the origin funds.
once collected into a group of transactions and added the id of previous block. you then secure your block with a strong id. that way if anyone tries to change the past they have to change everything that happened after that point as the hashes thy have and the hashes you have wont match.

It seems this somehow answer your question


https://www.verypossible.com/blog/blockchain-explained-how-does-immutability-work

As I understand it, it became immutable once a block (containing all the data) is  published/broadcast and verified by other nodes. Anyone? Please correct me if I am wrong.

I'm a new comer to bitcoin but I am intrigued by the idea and the implementation. I still find myself confused regarding some basic concepts. Hopefully I don't belabor your patience but perhaps this is a hint that maybe we need to work on the documentation a bit more.

my Question
I guess a lot of my confusion revolves around what a transaction is. Perhaps I have missed something but it seems to me that any documentation I have read seems to gloss over what a transaction is. If blocks form a chain and must be solved, and if the solution of the block depends on the hash of the block, doesn't adding a transaction to a block invalidate the solution? If the number of blocks are finite and blocks are not mutable (transactions cannot be added to them), doesn't that imply that the number of transactions is also finite.