Topic: luke jr's solution: make the blocks smaller (Read 1983 times)

Faster 1-conf transactions are not bitcoin's big issue though.

Why do you feel that is the most pressing matter?

Obviously that is not going to help anything if
there's a logjam in the memepool unless you actually
increase bandwidth.  ...and making the blocks smaller
certainly goes against that anyway.

remember the 10 minute thing is not a 10 minute thing(in code)

its a difficulty with hopes that 2016 blocks are  made in 2 weeks.
its then the human mind that away from bitcoin code, which then does some maths to realise that it averages 10 minutes. and is only "10 minutes" at conversation level, not code level
sometimes though reality reveals a block is solved in just a couple minutes or nearly an hour.. but blocks are not locked to 10minutes and 0 seconds.

in short: there is no "10 minutes" in the code..

now if you want4032 blocks in 2 weeks (to human brain maths away from code, average 5min)
expect luck to make blocks in say 1 minute more often and still have some blocks taking an hour

this issues with (human brain 5 minutes)
1. 10mins or 5 mins or 2 minutes.. still are too long for the 'grocery checkout line experience'
2. due to the amount time to see a new block, download it verify it and be ready to relay it out.. multiplied by each relay hop.. (propagation time) can cause issues if there is not a healthy gap between blocks
3. changing a couple lines of code to get dynamics vs changing block reward, difficulty, halving reward schedule, etc.. you prefer to stupidly scrambling all the rules rather than just changing one.

Sometimes I think I'm posting to a brick wall.

I've been saying that we need shorter block generation times, and smaller blocks (500Mb)  for well over a year.

lol
read harder.
they removed PART of it in 0.12.1, and more in 0.13

core are known to find faults in early versions. and things they missed/skipped.
but instead of updating early versions to be bug free. they just move to the next version and leave previous versions with bugs open to download with the bugs/issues still there cluttering the code..

thus if people were required to DOWNGRADE. they would not get a better old version than the first time they downloaded the old version last year.

imagine it this way
imagine if microsoft finds a issue in windows 8 and fixes it in an upcoming windows 11.. but doesnt go back and make a windows 8.x or windows 10.x fix..
they just moved onto version 11..

well thats what core do.
not fix the version with the issue or clean up things they missed.. instead they only care about the latest upcoming version..
(P.S i know microsoft do patch old versions, i was just saying 'IF' as an example)


it was already part removed AKA unusable
BU was just clearing the remnants..
to establish the alert key again requires a new mechanism / key.. and then the community would never hear the end of a debate that BU have a key to alerts twisted into BU control alerts and will broadcast propaganda.

so removing redundant code seems natural.. call it a spring clean exercise

No offense , but that is just stupid.  
Why don't we all turn our TVs & Radios off, because we don't want to hear a message about an impending disaster, that we could avoid if we knew about it.

By that argument we should scrap the Emergency Broadcast system that warns us of impending Weather Dangers.  

 

FYI:
They don't have a grown up there , that would not spam the network with Viagra ads.

Agreed with the last quote. My guess is BU removed the alert key as it could have been used as an attack vector.

Yes it was removed by core last year. BU decided to remove it 10 days ago. If they felt there was a good reason for it, they would've kept it.

it comes down to this:

lol the alert was removed in core last year
when bu grabbed core code. BU cleaned out the clutter of the last remnants of unneeded code

Why did Bitcoin Unlimited do it too?


Bitcoin Unlimited: https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/360
Title: Removal of alert system #360

By the way, Bitcoin contains "partition detection" and still does alerts for that. Though I don't know if that triggers with a different version block. It definitely won't kill the chain though, it's just a message. If it killed the chain, a rogue miner could shut down the network. EDIT: it's supposed to trigger when it detects a fork.

That's kind of not answering a question by asking another question.
A centralised alert key system should not be a long term solution.

why do you think segwit team disabled the alert message system with some foolish crap about the keys may be compromised

why do you think they went soft instead of letting nodes upgrade first and show network confidence .. and then do a pool vote secondary..
think about why they avoided nodes first.

oh and why are they now FORCING a mandatory activation without conceding if they dont get the votes

If blocks have a version number, and a hard fork results in a new block version, isn't just the receipt of a block version higher than your node expects enough to trigger an upgrade alert? Could a consensus cryptographic solution be put in place to protect this (rogue version block attacks, and killing the old blockchain fork by rendering it unworkable?)

Well, Bitcoin Unlimited did remove it too. It's a dangerous feature. Compromising that key would allow someone to spread panic and crash the price.

Core is really a bunch of NitWits, they could have just changed the Alert key so that it was different from the previous key.
Seems like Core has been setting you guys up for quite a while now. 


 

FYI:
Well , that leaves the Forums, News & Radio & Email & Web Ads , and Phone Calls directly to the Big Pools.
Still more than enough ways for everyone to be informed.

Core: https://bitcoin.org/en/alert/2016-11-01-alert-retirement
Bitcoin Unlimited: https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/360

in short:

Well that was stupid.

Who did that?


 

The alert system was removed a year ago.

If they don't update, once the fork happens, they won't receive be able to send or receive BTC until they do.
If they waited til after it forked, they will have to update to the new wallet, and then redownload the blockchain and -reindex to make sure all of their coins amounts are accurate. If they are too stupid to do that, they really need to let someone else manage their wallet.
Which by the way , the majority of BTC users do let others manage their wallet.

 

FYI:
Coins sent out on a bad fork are not lost , because when you reindex, (it is like they were never sent out.)  

FYI2:
You Guys do know the Dev Team can broadcast a message out that pops up on All of your BTC wallets until you update.
The Message could say ,  Hard Fork ahead Update before May 15th.

altcoin, can do hard fork without worry too much what are the consequence, because they are not as a big as bitcoin, they have no merchants not anything important that need to upgrade their blockchain in case of hard fork

this is a big difference, with an hard fork(not chain split) all miners and merchants need to upgrade, what if someone do not? might result in a mess with some transactions that are lost, because sent to the old fork

In the old days everyone ran a node. Running a full node was just as convenient as running an SPV client, with the added bonus of privacy and extra security. You have no privacy when you use an SPV wallet. All your Bitcoin addresses are sent to the node and they can see every transaction in your wallet.

Now running a full node requires doing an initial sync for a few days and 300+GB bandwidth a month and a minimum of 2GB RAM dedicated to the node.

Increasing the blocksize will only make this worse. The more you increase it, the worse it gets, and it's not even linear, a doubling of blocksize requires more than double bandwidth. Eventually nodes will become so expensive to run only a few people will be able and the network will become highly vulnerable and centralized and very easy to attack or even shut down.

To make it even worse, the max blocksize that the code can handle right now is 72MB. This isn't nearly enough to scale to the size of visa. Another scaling solution is needed. My preferred solution is: short term, a small increase in blocksize. Medium term, LN to make microtransactions possible again and get all small value transactions off the chain. Long term, MimbleWimble sidechain, possibly won't even need LN anymore when thats done. We need segwit to do all these 3.