Bitcoin Forum
May 25, 2019, 11:01:52 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Luke Jr's 300kb blocks  (Read 757 times)
gentlemand
Legendary
*
Online Online

Activity: 2016
Merit: 1699


Baby Blue Panties


View Profile
February 12, 2019, 07:14:14 PM
Merited by Welsh (5), suchmoon (4), infofront (1), HeRetiK (1), VB1001 (1)
 #1

I see this subject has bubbled up again on Twitter and Luke Jr is proposing an experimental soft fork with smaller blocks.

https://cryptoinsider.com/on-reducing-the-bitcoin-block-size-to-300kb/

Rather unfortunately it appears to have been latched on to by the usual casualties who zombified themselves with BCH and other dead ends. They're expressing lots of 'concern' about ongoing sustainability now Bitcoin turns out to have had big blocks all along.

Does it have any merit as an idea or is the entire thing one guy's worry being twisted into yet another attempt to undermine BTC?


1558782112
Hero Member
*
Offline Offline

Posts: 1558782112

View Profile Personal Message (Offline)

Ignore
1558782112
Reply with quote  #2

1558782112
Report to moderator
PLAY OVER 3000 GAMES
LIGHTNING FAST WITHDRAWALS
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558782112
Hero Member
*
Offline Offline

Posts: 1558782112

View Profile Personal Message (Offline)

Ignore
1558782112
Reply with quote  #2

1558782112
Report to moderator
1558782112
Hero Member
*
Offline Offline

Posts: 1558782112

View Profile Personal Message (Offline)

Ignore
1558782112
Reply with quote  #2

1558782112
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
February 12, 2019, 07:33:22 PM
 #2

one guy's worry being twisted into yet another attempt to undermine BTC?
I never even heard of it until your link.  So yes.
Carlton Banks
Legendary
*
Offline Offline

Activity: 2380
Merit: 1673



View Profile
February 12, 2019, 07:39:00 PM
Merited by bones261 (2), JayJuanGee (1)
 #3

It's a really old proposal. I thought it was trying to be too smart/subtle.


The idea was to reduce to 300kB base size, but also set a graduated increase schedule, based on absolute block heights (the 300kb step was set to take place at a blockheight back in 2017 IIRC). It finally reached 1MB base size again in 2024, and continued at a percentage rate (also IIRC). In other words, if the proposal was adopted today, we'd be past the 300kB stage already.

This was partly a psychologically based proposal, which is why people reacted badly, lol. I think Luke knew that 300kB base size would get laughed off, but he figured that since the blockchain grows constantly, that the closer we get to 2024 (when 1MB base would be reached again), the more people might begin to realise that reducing from the 1MB base size was smarter than it sounded back when the blockchain was a more manageable size.

Note that all of this is using base block figures, the real possible block size would be x2-4 the base block (so 300kb would in fact be 600-1200kB if all transactions in a given block are segwit txs).

Bear in mind that as we're still not in 2024, Luke's plan may actually work, and reducing the base from 1MB to whatever the schedule would be stepped to now (which has of course increased beyond 300kB) might look good to some people. It would probably still take some convincing, but there's still 5 years left on the clock.

Vires in numeris
andreibi
Legendary
*
Offline Offline

Activity: 1436
Merit: 1008



View Profile
February 12, 2019, 08:04:25 PM
 #4

We're going to have to wait until the Lightning network get to near or half capacity. So far, the current solution is working.

whitepaperDataBloc | website
The Airbnb of Data Services
Twitter | YouTube | Telegram | Facebook | LinkedIn | Reddit
aliashraf
Hero Member
*****
Offline Offline

Activity: 812
Merit: 622


View Profile
February 12, 2019, 10:06:59 PM
Last edit: February 12, 2019, 10:50:35 PM by aliashraf
 #5

What I get from Luke Jr's original tweet is about a demonstration to prove (to somebody?) that it is possible to have temporary soft-forks!

I don't see anything like an advocacy for such a change in Luk's tweet. The article OP has linked to is a different story tho....

I didn't have enough time to track the writer down but my first impressions are not encouraging. He is obviously twisting things for indirectly accusing Core team of being too much LN oriented and engaged in kinda conspiracy against bitcoin to reduce its throughput hence making fees to jump high and pushing people to layer-2 solutions like LN.

Edit: it is just ridiculous,  I  found more tweets from Luke, he is seriously championing for such a soft fork! The guy is getting completely out of rail by his fruitless obsession with decentralization, imo.
odolvlobo
Legendary
*
Offline Offline

Activity: 2506
Merit: 1315



View Profile
February 13, 2019, 12:38:19 AM
Merited by gmaxwell (1)
 #6

Articles about Twitter threads are stupid.

Buy bitcoins with cash from somebody near you: LocalBitcoins
Buy stuff on Amazon at a discount with bitcoins or convert Amazon points to bitcoins: Purse.io
Join an anti-signature campaign: Click ignore on the members of signature campaigns.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
February 13, 2019, 05:04:15 AM
Merited by leonair (3), LoyceV (2), aliashraf (2), Welsh (1), BobLawblaw (1)
 #7

The idea was to reduce to 300kB base size, but also set a graduated increase schedule, based on absolute block heights (the 300kb step was set to take place at a blockheight back in 2017 IIRC). It finally reached 1MB base size again in 2024, and continued at a percentage rate (also IIRC). In other words, if the proposal was adopted today, we'd be past the 300kB stage already.
That was the old thing, but apparently on twitter he's talking about something even less reasonable now.

In any case, I showed this thread to other developers and the response was uniformly a big wtf.

Initial sync time does suck and is a problem, but the damage has been done-- since long ago-- no amount of size reduction will solve it. If it would then perhaps these ideas would get a bit of traction, but it won't...
aliashraf
Hero Member
*****
Offline Offline

Activity: 812
Merit: 622


View Profile
February 13, 2019, 06:48:06 AM
Last edit: February 13, 2019, 08:20:02 AM by aliashraf
Merited by JayJuanGee (1)
 #8

What Luke is championing for (in Twitter  Grin) is both improving sync time and block propagation delay.

Of the two, the latter is improved by FIBRE a lot (very low << 0.001 orphan rates right now) and is under even more developments AFAIK but the first one,  initial sync time is an open problem.

As of initial sync problem,bootstrapping,  besides what Greg Maxwell has reminded above (Luke's proposal not helping with current situation just reducing the pace by which it is getting worse), I think there is definite need for the original problem to be addressed somehow.

In btctalk we've been discussing it recently:

here         https://bitcointalk.org/index.php?topic=5046152.msg46692966#msg46692966

and here: https://bitcointalk.org/index.php?topic=5103449.msg49479330#msg49479330
1Referee
Legendary
*
Online Online

Activity: 1890
Merit: 1303


View Profile
February 13, 2019, 08:28:46 AM
 #9

In any case, I showed this thread to other developers and the response was uniformly a big wtf.
He seems pretty vocal on Twitter, which actually worried me a bit, because it's beyond ridiculous to even suggest something like that where we are right now.

Initial sync time does suck and is a problem, but the damage has been done-- since long ago-- no amount of size reduction will solve it. If it would then perhaps these ideas would get a bit of traction, but it won't...
It's not as bad as it seems. If you're running a decent setup, the sync time is pretty reasonable actually. I set up a second node myself earlier this year, and it synced in like 11-12 hours, and that while I expected it to take a day at least. RPI's are a different story, but then again, run a decent setup and you don't have these problems.

In the end, the average person won't run a node even with a very small block size. Why? They just don't give a fuck. People who do give a fuck, and merchants, will continue to spec out their hardware to run their node in the most stable possible manner.

Luke Jr lost his mind.

aliashraf
Hero Member
*****
Offline Offline

Activity: 812
Merit: 622


View Profile
February 13, 2019, 09:14:17 AM
 #10

It's not as bad as it seems. If you're running a decent setup, the sync time is pretty reasonable actually. I set up a second node myself earlier this year, and it synced in like 11-12 hours, and that while I expected it to take a day at least. RPI's are a different story, but then again, run a decent setup and you don't have these problems.

In the end, the average person won't run a node even with a very small block size. Why? They just don't give a fuck. People who do give a fuck, and merchants, will continue to spec out their hardware to run their node in the most stable possible manner.
Are you arguing like "it is just fine, people should sit on the backbone (like me) and boot in half a day if they got real incentives, being a bitcoin whale (like me)" ? And you expect Luke to appreciate your argument and back-off?  Grin

Average users have incentives to join, like you and other bitcoin whales Tongue they just can't and it is getting worse as the time passes. A UTXO commitment/reconciliation protocol could change the scene radically, imo.

1Referee
Legendary
*
Online Online

Activity: 1890
Merit: 1303


View Profile
February 13, 2019, 09:34:32 AM
 #11

Are you arguing like "it is just fine, people should sit on the backbone (like me) and boot in half a day if they got real incentives, being a bitcoin whale (like me)" ? And you expect Luke to appreciate your argument and back-off?  Grin
It worked till where we are today, and the number of nodes continues to increase. That's not exactly a sign of there being a problem, or does it? Roll Eyes

If you also add that with Lightning growing even more nodes will pop up, because whoever the operators are, there is a financial incentive to run a node now, so the number of nodes will continue to increase.

Average users have incentives to join, like you and other bitcoin whales Tongue they just can't and it is getting worse as the time passes. A UTXO commitment/reconciliation protocol could change the scene radically, imo.
Average user incentives are buy in low and sell higher. They use light weight clients, or they don't use a client at all, but leave their coins on an exchange.

Don't break something that works extremely well today. We know that it works. Messing around with something so important is a gamble, and will likely drive people away from Bitcoin.

Carlton Banks
Legendary
*
Offline Offline

Activity: 2380
Merit: 1673



View Profile
February 13, 2019, 10:26:17 AM
 #12

That was the old thing, but apparently on twitter he's talking about something even less reasonable now.

In any case, I showed this thread to other developers and the response was uniformly a big wtf.

I see. Ok, Luke's a bit single-minded about 300kB. This completely invalidates my interpretation of the old proposal; it seems he even wanted everyone to take a 300kB base size seriously even back when he first promoted it.


Initial sync time does suck and is a problem, but the damage has been done-- since long ago-- no amount of size reduction will solve it. If it would then perhaps these ideas would get a bit of traction, but it won't...

Wasn't there an idea from sipa to change how transactions are serialized that reduced the entire chain's size? If one cares about IBD, one ought to be most interested in proposals that remediate the historic chain size as well as those that improve it forwards in time.

Vires in numeris
aliashraf
Hero Member
*****
Offline Offline

Activity: 812
Merit: 622


View Profile
February 13, 2019, 10:38:44 AM
 #13

It worked till where we are today, and the number of nodes continues to increase. That's not exactly a sign of there being a problem, or does it? Roll Eyes
Actually the number of nodes has slightly decreased in 2018 while bitcoin continues to grow and becomes more popular, so yes, there is a problem.

Quote
If you also add that with Lightning growing even more nodes will pop up, because whoever the operators are, there is a financial incentive to run a node now, so the number of nodes will continue to increase.
LN nodes can do their job by connecting to light clients like spruned and running LN nodes is not much of a financial incentive and do not compensate for fancy full node setups.

On the other hand given mass adoption of LN, channel setup/flush operations will load the network even more.
It is what Luke jr fails to understand, he thinks people migrate from main chain to layer-2, it is not exactly what happens when LN gets adopted, instead new use cases would emerge.

Quote
Average users have incentives to join, like you and other bitcoin whales Tongue they just can't and it is getting worse as the time passes. A UTXO commitment/reconciliation protocol could change the scene radically, imo.
Average user incentives are buy in low and sell higher. They use light weight clients, or they don't use a client at all, but leave their coins on an exchange.
Current spv wallets should be eliminated and replaced with pruned full nodes (that sync fast, imo) Luke is right in this respect: Don't transact if you can't verify.

Quote
Don't break something that works extremely well today. We know that it works. Messing around with something so important is a gamble, and will likely drive people away from Bitcoin.
Not a best engineering practice at all. Improvements are inevitable we just have to be cautious and not to panic.
"Extremely well" was too much by the way. Wink
BobLawblaw
Legendary
*
Offline Offline

Activity: 1288
Merit: 1909


BitcoinTalk's Most Fabulously Gay Black Power-Top


View Profile
February 13, 2019, 12:16:23 PM
Merited by kano (5), figmentofmyass (1)
 #14

Luke Jr lost his mind.

An argument can be made that Luke Jr was never in a rational frame of mind, to begin with.
aliashraf
Hero Member
*****
Offline Offline

Activity: 812
Merit: 622


View Profile
February 13, 2019, 12:48:06 PM
 #15

Luke Jr lost his mind.

An argument can be made that Luke Jr was never in a rational frame of mind, to begin with.
Grin Grin
Sorry couldn't help it, can't.  Cheesy
1Referee
Legendary
*
Online Online

Activity: 1890
Merit: 1303


View Profile
February 13, 2019, 12:50:41 PM
 #16

Actually the number of nodes has slightly decreased in 2018 while bitcoin continues to grow and becomes more popular, so yes, there is a problem.
Fluctuations are pretty normal, especially with how the bear market made lots of 'enthusiasts', startups and services quit, and thus they take down their nodes.

https://bitnodes.earn.com/dashboard/?days=730

As you can see, there is steady/healthy growth. The size of the chain has grown significantly, but the number of nodes increased regardless of that. So no, there is no problem. Smiley

On the other hand given mass adoption of LN, channel setup/flush operations will load the network even more.
It is what Luke jr fails to understand, he thinks people migrate from main chain to layer-2, it is not exactly what happens when LN gets adopted, instead new use cases would emerge.
What bothers me more is that he is basically betting on a measure that will force people to layer 2, and that's something you don't do. Stimulating free use of the network is what we have always had, and that's exactly why Segwit adoption isn't picking up. I don't like that certain entities aren't upgrading, but on the other hand, that's the freedom they have, and we should respect that. Bitcoin is freedom at the end of the day.

Current spv wallets should be eliminated and replaced with pruned full nodes (that sync fast, imo) Luke is right in this respect: Don't transact if you can't verify.
Not much to disagree with here, but hey, it all comes down to the freedom aspect. People can choose whatever they think offers the most usefulness to them.


"Extremely well" was too much by the way. Wink
Right. It works well enough in its current state is more fitting I guess. Tongue

An argument can be made that Luke Jr was never in a rational frame of mind, to begin with.
That cracked me up, lol. Cheesy

Carlton Banks
Legendary
*
Offline Offline

Activity: 2380
Merit: 1673



View Profile
February 13, 2019, 01:46:55 PM
 #17

Luke Jr lost his mind.

An argument can be made that Luke Jr was never in a rational frame of mind, to begin with.

Luke has eccentric ideas for sure, but he also has good ideas that get adopted.

Vires in numeris
BobLawblaw
Legendary
*
Offline Offline

Activity: 1288
Merit: 1909


BitcoinTalk's Most Fabulously Gay Black Power-Top


View Profile
February 13, 2019, 02:20:35 PM
 #18

Luke has eccentric ideas for sure, but he also has good ideas that get adopted.

"Even a stopped clock..."
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
February 13, 2019, 02:27:20 PM
Last edit: February 13, 2019, 02:45:47 PM by gmaxwell
Merited by Welsh (5), ETFbitcoin (1), bones261 (1), aliashraf (1), MagicByt3 (1)
 #19

"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."

That said ... there are degrees. Smiley

I'm disappointed with the press circus Luke has contributed to here, -- it's not the first time he's set things up perfectly for his words to be taken out of context and then been so so surprised at what happened. But he does make useful contributions, and in the fullness of time drawing more attention to the initial sync problem may be one too, even though I disagree with the approach.

As you can see, there is steady/healthy growth.
Careful with those assumptions,  if you filter out nodes from a couple popular VPS providers and nodes that have obvious behavioral tells that they're fake... the picture looks much less rosy.  A lot of "nodes" are sybils setup-- presumably-- to track transaction origins.

Wasn't there an idea from sipa to change how transactions are serialized that reduced the entire chain's size? If one cares about IBD, one ought to be most interested in proposals that remediate the historic chain size as well as those that improve it forwards in time.
Blockstream has unpublished code that implements an alternative serialization that reduces tx sizes by around 25%.   I don't think it would actually improve IBD time except for very fast computers on fairly slow internet connections... initial sync is more utxo-update bound than bandwidth bound for most users. It might even slow it down, since the compact serialization is slower to decode. On a ludicrously fast machine (24 core 3GHz, nvme storage, syncing from local hosts over 10gbe) sync currently only proceeds at about 50mbit/sec.  I've been nagging them to publish it.  Their interest is in using it to increase capacity on the sat signal, but it's more generally useful.

I expect and hope that all the IBD activity will move into the background. After that happens, then the time it takes is less important than the resources-- and at that point a 25% bandwidth improvement would look pretty good.
Carlton Banks
Legendary
*
Offline Offline

Activity: 2380
Merit: 1673



View Profile
February 13, 2019, 02:37:00 PM
Last edit: February 13, 2019, 03:05:56 PM by Carlton Banks
Merited by bones261 (2), ETFbitcoin (1)
 #20

So Luke's new proposal is actually a way to soft-fork to 600k weight units, which is not at all the same as 300kB.

That's truly bizarre as an idea, apologies to Luke. That would mean keeping the base size at 1MB, and only being able to use 600kB within that base limit. The segwit discount would still reduce fees for segwit tx's, but the incentive to use segwit tx's as a way to boost capacity would disappear if the base size (1MB) was higher than the weigh limit (600kWU). Don't see the rationale for that at all.


I'm disappointed with the press circus Luke has contributed to here, -- it's not the first time he's set things up perfectly for his words to be taken out of context and then been so so surprised at what happened. But he does make useful contributions, and in the fullness of time drawing more attention to the initial sync problem may be one too, even though I disagree with the approach.

It seems like Luke has a fascination for exploring possibilities without much reasoning as to why the ends are desirable. In the case of the actual BIP141 segwit soft fork, that approach was great, as Luke was motivated to figure out a way to implement segwit. Someone with an "it'll never work" attitude would never have done so.


Blockstream has unpublished code that implements an alternative serialization that reduces tx sizes by around 25%.   I don't think it would actually improve IBD time except for very fast computers on fairly slow internet connections... initial sync is more utxo-update bound than bandwidth bound for most users. It might even slow it down, since the compact serialization is slower to decode. On a ludicrously fast machine (24 core 3GHz, nvme storage, syncing from local hosts over 10gbe) sync currently only proceeds at about 50mbit/sec.  I've been nagging them to publish it.  Their interest is in using it to increase capacity on the sat signal, but it's more generally useful.

50Mbit/s is high-end validation performance? Interesting.


I expect and hope that all the IBD activity will move into the background. After that happens, then the time it takes is less important than the resources-- and at that point a 25% bandwidth improvement would look pretty good.

Are you referring to the hybrid SPV concept? (SPV synchronisation finishes first, IBD continues in the background). Or new UTXO set tech?

Vires in numeris
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!