Quick Question

[jyakulis]

I'm not a programmer but it bothers me that gigawatts of electricity and CPU power go into mining bitcoin and the transaction speed is so slow. Well, at least I've read that it was slow.

Why can't you just create an option for miners to either spend cpu power confirming transactions on the network or split their cpu power on both? Wouldn't some kind of balance be struck where more cpu power would go toward confirming transaction fees and running more small nodes vs. rewards for minting new coins. Or could transaction fees be split equally amongst all confirming nodes to get more people running a node? I'm thinking like whattomine, where you are like oh it's better to mine this based on expect ROI. Is the confirmation process nothing to do with cpu power but more related to this memory issue?

[1713291358]

1713291358

[1713291358]

1713291358

[1713291358]

1713291358

[DannyHamilton]

I'm not a programmer but it bothers me that gigawatts of electricity and CPU power go into mining bitcoin

And how much energy goes into manufacturing, transporting, securing, and transacting U.S. dollars throughout the entire world?

and the transaction speed is so slow. Well, at least I've read that it was slow.

Slow? Every transaction I've ever sent or received has been received within a couple of seconds.  Then within an average of 10 minutes is is permanently irreversible.  Can you say the same about bank transfers?

Why can't you just create an option for miners to either spend cpu power confirming transactions on the network or split their cpu power on both?

I don't understand the question.  Have you read the whitepaper yet? Do you understand what problem Bitcoin solved, and how it solved it

Wouldn't some kind of balance be struck where more cpu power would go toward confirming transaction fees and running more small nodes vs. rewards for minting new coins.

The process of confirming transactions IS the process of minting new coins.  There is nothing to split.

Or could transaction fees be split equally amongst all confirming nodes to get more people running a node?

Nodes don't confirm transactions.  Transactions are confirmed by being included in a block by a miner.

I'm thinking like whattomine, where you are like oh it's better to mine this based on expect ROI. Is the confirmation process nothing to do with cpu power but more related to this memory issue?

The confirmation process IS the mining process.

[amaclin1]

And how much energy goes into manufacturing, transporting, securing, and transacting U.S. dollars throughout the entire world?

you should compare apples-to-apples, oranges-to-oranges
transaction natural cost in fiat and transaction natural cost in crypto

[jyakulis]

I'm not a programmer but it bothers me that gigawatts of electricity and CPU power go into mining bitcoin

And how much energy goes into manufacturing, transporting, securing, and transacting U.S. dollars throughout the entire world?

and the transaction speed is so slow. Well, at least I've read that it was slow.

Slow? Every transaction I've ever sent or received has been received within a couple of seconds.  Then within an average of 10 minutes is is permanently irreversible.  Can you say the same about bank transfers?

Why can't you just create an option for miners to either spend cpu power confirming transactions on the network or split their cpu power on both?

I don't understand the question.  Have you read the whitepaper yet? Do you understand what problem Bitcoin solved, and how it solved it

Wouldn't some kind of balance be struck where more cpu power would go toward confirming transaction fees and running more small nodes vs. rewards for minting new coins.

The process of confirming transactions IS the process of minting new coins.  There is nothing to split.

Or could transaction fees be split equally amongst all confirming nodes to get more people running a node?

Nodes don't confirm transactions.  Transactions are confirmed by being included in a block by a miner.

I'm thinking like whattomine, where you are like oh it's better to mine this based on expect ROI. Is the confirmation process nothing to do with cpu power but more related to this memory issue?

The confirmation process IS the mining process.

I have no idea about banking cpu power.

I just see a lot of people complaining about the transaction times. I have no idea though.

My question I guess is what is the fundamental reason for the perceived and future limitations of transaction confirmations?

Ok, so the block contains all the transactions that occurred in that block as well as the mined block? I get it but it can be hard for me to wrap my head around some times. I think I see now. I just was wondering if there was any way to make them interconnected yet separate. But it seems like no. So when you get a block in a mining pool the coins are confirming the series of transactions that occurred so, if they get a spike in one block then it can be slower than how fast they solve the next block? I think that's right, right?

Can you explain difficulty?

I did read the white paper but I don't know if I completely understood it. I'll have to go back over it one of these days. It just seems like a lot of cpu power. The block time is always the same and they always solve it in 10 minutes but the confirmation can take longer. I don't understand that really. Why do these blocks always have to be static at a time limit?

Also, why didn't they just make the coin supply increase in some in relationship to Moore's law since they were using CPU power?

[ranochigo]

My question I guess is what is the fundamental reason for the perceived and future limitations of transaction confirmations?

Number of transactions that can fit inside a block.

Ok, so the block contains all the transactions that occurred in that block as well as the mined block?

Contains the transactions that was in the mempool, as well as the Coinbase of that block.

So when you get a block in a mining pool the coins are confirming the series of transactions that occurred so, if they get a spike in one block then it can be slower than how fast they solve the next block? I think that's right, right?

I don't know what you are talking about. If you are talking about a spike in the number of blocks generated in one unit time, its a no. If you are talking about the number of transactions in a block affecting the speed of the finding, its also a no. Since you are just hashing the block header, its essentially the same with finding a block with 1 transaction.

Can you explain difficulty?

Difficulty is the measure of how difficult it is to find a hash that is below the target. The block is valid only when the hash of the block header meets or is below the target.

I'll have to go back over it one of these days. It just seems like a lot of cpu power. The block time is always the same and they always solve it in 10 minutes but the confirmation can take longer. I don't understand that really. Why do these blocks always have to be static at a time limit?

The blocks can only contain this much transactions. Not every single transaction on the network can fit inside the block. The time interval is probably set also to regulate the distribution of Bitcoin.

Also, why didn't they just make the coin supply increase in some in relationship to Moore's law since they were using CPU power?

Supply and demand. If the coin supply is increased due to the increase in mining hashrate, the price of Bitcoin won't be this high today and the miners probably would still earn the same amount.

[cdb1690]

Ok, so the block contains all the transactions that occurred in that block as well as the mined block?

Block contains a list of yet unconfirmed transactions as well as one special transaction called coinbase transaction. This transaction is created by the miner and it currently pays 12.5 BTC to the miner. It has two basic purposes: to reward miner for creating the block & to create new money supply.

Now it might seem that practically anyone can take a list of unconfirmed transaction, add coinbase transaction on the top of that and create a new block. But it's not as simple as that. For a block to be valid, it has to be constructed in such a way, that its hash (or more precisely the hash of its header) is smaller than certain number called difficulty target. And this difficulty target is regularly adjusted so that it takes on average 10 minutes for the network to find a new block.