Re: Does lightning network really solve the scalability problem?
Bitcoin Blocks can hold a Maximum of ~1.7MB [~7200 transactions] so ~12 transactions per second
Wrong, check those blocks :
1. https://blockchair.com/bitcoin/block/566575
| Size (bytes) | 2,377,364 |
| Weight (weight units) | 3,993,179 |
| Stripped size | 538,605 |
2. https://blockchair.com/bitcoin/block/367853
| Transaction count | 12,239 |
My Bad,
https://www.youtube.com/watch?v=dsUXAEzaC3Q
https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-what-would-be-the-max-number-of-transaction-confi
Quote
A corresponding non-segwit transaction would have a size of 192 bytes,
which, together with the 1MB size limit brings us to 5208 transactions per block,
compared to 12195 max segwit transaction per block.
which, together with the 1MB size limit brings us to 5208 transactions per block,
compared to 12195 max segwit transaction per block.
@ETFbitcoin,
Interesting enough your reference block exceeded the max of even all segwit only transactions in the above quote and according to the block height was years before segwit was even activated.
https://www.reddit.com/r/Bitcoin/comments/ail257/interesting_fact_the_most_number_of_transactions/
Quote
Most of these transactions were tiny. The average transaction size in that block was 81.7 bytes. Many (like this one) were 62 bytes. These were unsigned transactions. The scriptsig for these transactions was just "1". A single byte. No ECDSA, no pubkey hash. No security. The output scripts that these transactions were spending were literally empty.
Also interesting , is this block was useless in clearing the backlog. 2015-08-01 01:06 (4 years ago)
https://www.reddit.com/r/Bitcoin/comments/3fd2a9/f2pool_setting_a_new_record_most_transactions/
Quote
This is a bit complicated...but they are cleaning up zero-valued UTXOs that F2Pool themselves created in their last spam cleanup.
To elaborate: See this Example. Notice the input is 0.0BTC from a F2Pool UTXO created on Jul 10th. During the last spam cleanup F2Pool attempted to save a byte by sending 0.0BTC to the empty script, rather than OP_RETURN'ing it. However, this creates a spendable zero-valued UTXO which bloats the UTXO-set. It appears that F2Pool are now clearing aways these UTXOs.
This does nothing to help the current backlog.
To elaborate: See this Example. Notice the input is 0.0BTC from a F2Pool UTXO created on Jul 10th. During the last spam cleanup F2Pool attempted to save a byte by sending 0.0BTC to the empty script, rather than OP_RETURN'ing it. However, this creates a spendable zero-valued UTXO which bloats the UTXO-set. It appears that F2Pool are now clearing aways these UTXOs.
This does nothing to help the current backlog.
FYI:
@Bob123,
You're still Stupid.
FYI2:
https://www.blockchain.com/en/charts/n-transactions-per-block?timespan=all
*Average Number Of Transactions Per Block has always been below 3000 transactions per block,
so the max is no where near the average.*