Bitcoin Forum

anyone else agree with this? 

https://np.reddit.com/r/Bitcoin/comments/61yvvv/request_to_core_devs_please_explain_your_vision/dficjhj/

luke-jr's ideas never seem to have much acceptance. He gets most of his facts straight, however:


luke-jr still says that the blockchain is inefficiently used, which derives from his known "blacklist". He has taken a stance on certain transaction labeling them "inefficient" now and even "spam" in the past. The question is: who are we to take a stance regarding any kind of transaction? At least at transactions whose purpose isn't to disrupt the network.


Another imprecision is that LN does not improve the efficiency of the blockchain...

So yeah, there's that... I guess I'm not really in agreement. At least I don't agree with implementing his ideas.

I thought his blacklist was just for the Gentoo ebuild and never made it upstream. I also think that his blacklist was just a way for him to push his religious agenda, and doesn't really have anything to do with scaling Bitcoin.

Yeah it is just his gentoo build. He isn't entirely wrong though in that there are people wasting their money by making spammy transactions to fill up the blocks. Thats why the fees suddenly drop every so often, because the attack stops.

So miners are the ones to blame here? We were told by miners propaganda that big blocks are the only viable solution to scaling problem.

While in reality:

"Miners are de facto cheating by skipping the very validation that is a crucial part of their job.
This breaks the little security light clients had. The cause for this is the time it takes to verify large blocks."

Also this point seems very pleasing:

"today, hardforks are not safe. GIven a few years more on this research, it should be possible to make an uncontroversial hardfork equally as safe as a softfork"

We need to wait what will franky1 say about this new level of core devs lunacy.

If  block time gets smaller by a factor > 2 and 21 Mio are constant I m fine....

He is literally Talking out of his Ass.


If the Crybabies can't pull off a hard fork, Fire them.

BTC is pricing itself out of the markets , sending money orders is now cheaper.

Smaller Blocks , just mean less transaction fees for the miners and more Offchain is required.

If anyone has not figured out BTC Core is LN/Bankers Bitch, they are not paying attention.

BTC Core lies all of the time claim BTC can't do this or it can't do that.

ALT coins have been doing what they clam BTC can't for over 3 years. (They are LYING!)

 8)

FYI:
Increasing Blocksize or a Faster BlockSpeed , Either would Solve the Current ONCHAIN Issues.

wonder why full nodes are under 85%

1. core invent prunned mode
2. core tell the comunity its fine to use

3. core then complain its diluting the node count..

its called shooting self in the foot with "its ok"

same is happening with cores "its ok to be a downstream bottom tier of cores segwit network
same with
its ok to be a no witness

---

hey luke(if ur reading this). no matter what size you make the blocks.. bigger or smaller.. if you then add a feature to prune/no witness the full node even further.. ur still going to end up with a cesspool of nodes that cant be used as syncing seeds or full blockchain validators.

yep make the blocks just 50kb and people will still enable features to crapout the node count.. because core allow it.

---

.. hey core.. leave the prunned non-archival, lite wallet crap for things like armory and electrum to invent.


P.S i made this complaint nearly a year ago...


now core are blaming others yet its actually a core feature which they thought was "ok" to add to their full node..

The world is moving forward growing every day we can't just shrink and get smaller blocks and there is no way to determine which transactions are unneeded or inefficient other than the obvious spam attacks that now been revealed that they are to push the BU and other bigger blocks agendas.

With faster than 10 min block speed miners will mine more bitcoins and as a natural result the price will decrease.
I'd say lets make the fees to increase to a point where only the real supporters and users remain and spammers (aka BU dry out of money)
But that would mean nothing since they can keep mining their own spam transactions and earn back the fees that they've paid.

Correct. For him, things are co-related because he assumes these transactions can be discarded, thus making the blocks free up...


Attackers have nothing to do with this. The blacklist targeted transactions from online casinos and a few more sites I don't remember from the top of my head. Now the question is: why aren't those transactions legitimate and what makes them less legitimate than our transactions?


This is a fact, but they can still say whatever they want about blocks.


Take a note that fast block speeds aren't a bed of roses. And miners will probably be against it (higher chance of orphans)

Oh Please, don't tell me you believe their Crybaby bullshit.

Change the Block speed to 5 minutes instead of 10 , you double the transaction capacity without touching the blocksize.

If they are that scarred of orphans , they can change the recommended confirmations from 3 to 6 , it would be finished in the same amount of Time either way.
LTC does 2½ minutes with only 6 confirms and never has a problem.

BTC code is not as Lame as Core makes out, Alts running at adaptive Blocksizes and faster than 1 minute blockspeeds have been out for years.

Core just wants you to think BTC is Lame, so they can force LN\Bankers Offchain Network down your Throats.


 8)

changing the blockspeed is never going to happen. 

who the hell am i to know better than him when it comes to bitcoin?

no doubt he's totally right but this guy's business is technical perfection. that can't happen in a vacuum when there's real demand eating away at it.

if he wants it to run the way he believes it should then he'll have to ask most of the users to leave.

i think you just answered your own question :)

It's a good solution instead of dumb increasing the block size. With segwit and side chains the scaling will be perfect. In programming it's better way to optimize things make them more petite. Google what was PC twenty years ago and what are they now.

Have you read the LN WhitePaper, apparently Not.

There is a specific attack to let someone Steal Funds, by spamming the ONCHAIN network , so the Time Locks Expire.
Smaller Blocks will make theft easier to achieve.


 8)
 

Somewhat Luke Jr is always an interesting Dev node usage is dropping because of the lack of benefits.
 
Syncing takes a long time at 1MB a block hence move to lightweight as people feel that is secure enough and downloading the full blockchain is no small size either you need fast enough internet to keep up as well so incentives would be beneficial but still end up resulting in a fork due to changing block rewards etc.

As for making blocks smaller it is feasible if we move to an asset class and build a non-blockchain transaction layer but even at that point we need a few years or consensus.

Alas we probably won't have those few years so in a conundrum.

Yes, I do believe, from what I've read on the forums during the years, that quicker blocks might not be the best solution. Some of their "crybaby bullshit" is right. Each camp has its own rights and wrongs.

to change the 'blockspeed'. is not just a few lines of code..it requires:
changing the reward per block
difficulty formulae
retarget period
block halving schedule
etc.

it effects many other things, like:
propagations times
tweaking reward unsettles peoples minds of the rarity/fixed release of new coins. not being as fixed as first thought.
and of course 5minutes is no better than 10minutes in reality of the "waiting at a grocery checkout aisle"

and still requires a full NODE and pool consensus. so its not going to be any less hassle of a consensus achieving event, it will actually be more hassle

however just moving the blocksize alone is less issues.

I have read the article and it was interesting how smaller blocks is fitted in todays situation. Maybe he is right and in the future we are all going to need the HArd fork without issues and is much safer compare to the hardfork today. Though there are some points that I dont get but I dont know if I agree with him that an increase in blocksize today is not needed.

Do you run a full node? if not, why?

Why doesn't he just have Jesus miracle a solution. Or maybe that's what happened. Me might have prayed for a solution and this is the best thing Jesus could come up with in a pinch.     

Yes. Jesus is an expert in "game theory economics and applied cryptography" ;)

I don't think he has prayed for a solution. He even proposed a change of PoW, that will kill the bitcoin certainly.

I don't run one, because Full BTC Node are basically working for Free.

Pay me and I will run one.  :)


 8)

Noob question:
If we make the blocksize lesser would that make the transactions take several hours to get confirmed ?
i mean we all know that there are multiple transactions in a single block.

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.

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

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.

 8)

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.

The alert system was removed a year ago.

Well that was stupid.

Who did that?


 8)

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

in short:

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.  :P


 8)

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.

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.

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?)

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

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 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.

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

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:

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

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.  :P

 8)

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

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

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.

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.

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.