BTC vs BTU

[5h4do3]

Bit of a noob here,

so they have been complaining and fighting about what to do with bitcoin and its scaling issues....
some say change the block size, others disagree etc etc etc security.... open source... etc etc etc

Ok...

IF BTC wants to give the finger to BTU its quite simple there no need to change the block size silly silly
change the interval and the reward per interval.

eg. bitcoin block every 10 minutes+-... 12.5 btc reward "yay" block size 1mb +-
change to block every 1 minute 1.25btc reward per block "yay" block size 1mb (same same but different) scaled 10 fold.
all bocks will be valued on the chain processing is done faster. which is what people want...

If you do variable block size couple of problems pools will wanna do bigger blocks first or withhold certifying big blocks buy other pools

this is what i see on the surface.......

Hash difficulty will equalize to make the 1minute block happen. so 2 weeks of shuffle shuffle and then bam scaled 10 fold... and if this problem happens again
change interval for 1 minute to 10 seconds etc etc...

that my 5c

[1713284776]

1713284776

[1713284776]

1713284776

[1713284776]

1713284776

[Yogafan00000]

Except for node bandwidth, memory and disk space, HF chaos, market dumping, etc, what could possibly go wrong??

Let's call it BTFU.

[franky1]

eg. bitcoin block every 10 minutes+-... 12.5 btc reward "yay" block size 1mb +-
change to block every 1 minute 1.25btc reward per block "yay" block size 1mb (same same but different) scaled 10 fold.

1. messing with this involves
a. changing the reward mechanism - ugly thought, distrust that if it can be changed to 1.25 easily .. it can also be changed to 200000000000000 easily
b. changing the difficulty mechanism - ugly thought, 10x less hashpower required .. 10x more vulnerable to hash attack
c. changing the reward halving events from every 210k blocks to 2.1m blocks
d. issues with propagation

thats alot of rule changes just to still get 10mb every 10 minutes.. (data passing down cables over 10 minute average, no matter how you play with it as either 1x10 or 10x1)

ok lets delve into 1.d.
imagine it takes 10 seconds to get a block, validate it and ready to relay it out.
in 60 seconds the data has relayed through 6 'hops' of nodes.

..
but remember the block timing is not an exact science of 10min.. its an average. some blocks are solved in 2min some in 40 minutes.

so if we went to a 1minute average.. some blocks can be solved in 20 seconds.
meaning some nodes havnt even got the first block before the second block is trying to get around the network..
.. see the issue..?

this is why 10mins was suggested.. enough time to propagate around and have breathing room before the next block pops up even if that block was lucky to be solved in 2 minutes.
that cant be said for a lucky block of 20 seconds

and finally
2. even 1min is still too long for those complaining about the 10min queue when spending at the grocery store checkout argument

[XbladeX]

Except for node bandwidth, memory and disk space, HF chaos, market dumping, etc, what could possibly go wrong??

Let's call it BTFU.

BTC
- sewgwit // pack transactions making effectively from 1MB equal of 2MB
-Sewit fix malebility bug that is stoping many development fot BTC
-core - in 10 years you will be albe to download full blockchain like 250GB and validate your transaction alone
-segwit allows to use LN special channels taht are ultra fast in transfers low amounts so you won't ever border with 10min block at shop

BTU
- unlimited blocks so to keep with price per transaction like 0,2$ you need bigger block every 10x jump
like
1MB 1000USD/BTC = fee 0.2$
10MB 10 000USD/BTC = fee 0.2$
100MB 100 000USD/BTC = fee 0.2$0
- BTU won't fix malleability bug in BTC code they call it feature:D
- as clinet of BTU you will lost in 10 years ability to validate transactions you will have to use some datacenters that can handle like 100TB of data, regular user won't ever have control at this point. If those central DB will migrate to altchain you can do SHIT about it.
If miners decide to fork and move change like lift BTC hard limit you can do shit about it becouse those centers will carry transactions.
-btc lost goverment resistance
This is a biggest reason to avoid BTU

[franky1]

-Sewit fix malebility bug that is stoping many development fot BTC

only solved if EVERYONE.. well after activation. moves their funds from native keypairs to segwit keypairs. because only segwit keypair users are disarmed.. not the entire network
but malicious spammers will stick to native keys.. why would they choose to disarm themselves??
meaning malleability will still continue after segwit activates

when you realise the activation itself is not the defence but using segwit keys is disarming the volunteer who moves to segwit keys. you realise segwit has not 100% fixed malleability.

-segwit allows to use LN special channels taht are ultra fast in transfers low amounts so you won't ever border with 10min block at shop

multisig private offchain trades are done now.. segwit is not actually needed for LN function. its just an empty cry by core to find any excuse to sell people on segwits half promises

[jonald_fyookball]

Except for node bandwidth, memory and disk space, HF chaos, market dumping, etc, what could possibly go wrong??

Let's call it BTFU.

BTC
- sewgwit // pack transactions making effectively from 1MB equal of 2MB
-Sewit fix malebility bug that is stoping many development fot BTC
-core - in 10 years you will be albe to download full blockchain like 250GB and validate your transaction alone
-segwit allows to use LN special channels taht are ultra fast in transfers low amounts so you won't ever border with 10min block at shop

BTU
- unlimited blocks so to keep with price per transaction like 0,2$ you need bigger block every 10x jump
like
1MB 1000USD/BTC = fee 0.2$
10MB 10 000USD/BTC = fee 0.2$
100MB 100 000USD/BTC = fee 0.2$0
- BTU won't fix malleability bug in BTC code they call it feature:D
- as clinet of BTU you will lost in 10 years ability to validate transactions you will have to use some datacenters that can handle like 100TB of data, regular user won't ever have control at this point. If those central DB will migrate to altchain you can do SHIT about it.
If miners decide to fork and move change like lift BTC hard limit you can do shit about it becouse those centers will carry transactions.
-btc lost goverment resistance
This is a biggest reason to avoid BTU

you are only presenting once side of the centralization problem.

If Bitcoin is to scale with small blocks, then only institutions will be in control of transactions, opening channels with LN, etc.  Regulation can easily come in -- AML/KYC regulations for even using Bitcoin. 

Not sure if you simply don't realize this or you're intentionally being one-sided.

[Yogafan00000]

you are only presenting once side of the centralization problem.

If Bitcoin is to scale with small blocks, then only institutions will be in control of transactions, opening channels with LN, etc.  Regulation can easily come in -- AML/KYC regulations for even using Bitcoin. 

Not sure if you simply don't realize this or you're intentionally being one-sided.

I sorry that your upset that mainstream is taking away the fun Bitcoin play thing.  I was upset too.  I had to throw away all my miners because some bigwigs went ahead and funded ASIC dev. It sucks because all the fun was gone and now it seems miners are centralised also.

With big blocks, my node fun will diminish also because my wife gets pissed when Internet is too slow for facebooking.

Perhaps there is a future of fun tech in LN?  I would like to try to run some payment channels with my meager HODLings.

There is no stopping centralisation because efficiency.  People mostly hate to do the hard work.  They rather someone else worry about security.

[jonald_fyookball]

snip

its not that im upset.  im just trying to debunk some ignorance that there's only
1 kind of centralization or that big blocks create more centralization than small
blocks necessarily.

its debatable.  to me, transaction centralization is worse than node centralization

[5h4do3]

1. messing with this involves
a. changing the reward mechanism - ugly thought, distrust that if it can be changed to 1.25 easily .. it can also be changed to 200000000000000 easily 

***** "absolutely but every single miner in the world will see if it is wrong you cant hide this" in principle you still keeping with the cap of 21m of coins and the period in which it will be delivered

b. changing the difficulty mechanism - ugly thought, 10x less hashpower required .. 10x more vulnerable to hash attack

****** "no different to last year Jan wasn't hackable then wont be hackable now hash power still has to stay the same as you are doing more blocks more often you need to add up to 12.5btc reward if you dont keep the hash up you wont solve in time. your computing power is too low if you dont keep the hash up.

c. changing the reward halving events from every 210k blocks to 2.1m blocks

*******"which averages out so same same" they just put a "0" in the coding no? or where ever the 210000 pops up

d. issues with propagation "for sure btc btu btfu btxtc btabc doesnt matter propagation is always a problem"

thats alot of rule changes just to still get 10mb every 10 minutes.. (data passing down cables over 10 minute average, no matter how you play with it as either 1x10 or 10x1)

ok lets delve into 1.d.
imagine it takes 10 seconds to get a block, validate it and ready to relay it out.
in 60 seconds the data has relayed through 6 'hops' of nodes.

..
but remember the block timing is not an exact science of 10min.. its an average. some blocks are solved in 2min some in 40 minutes.

so if we went to a 1minute average.. some blocks can be solved in 20 seconds.
meaning some nodes havnt even got the first block before the second block is trying to get around the network..
.. see the issue..?

************** yeah this is the biggy how can it be solved?

this is why 10mins was suggested.. enough time to propagate around and have breathing room before the next block pops up even if that block was lucky to be solved in 2 minutes.
that cant be said for a lucky block of 20 seconds

*************** that doesnt make sense if your difficulty drops 10 fold and your hashing stays the same the computing time shortens 10 fold too so yes it will happen in seconds or 1 minute average

and finally
2. even 1min is still too long for those complaining about the 10min queue when spending at the grocery store checkout argument

*********** lol i still wait a minute for the credit card to connect at some store lol but good point hopefully people are too busy reading this forum to notice a minute has gone by

I wonder if by doing this if btc will have the scale of Visa