Satoshi Nakamoto: "Bitcoin can scale larger than the Visa Network"

[Lauda]

everything you hear about why we shouldn't increase blocksize is a bullshit excuse to delay the inevitable.

Nope. There are true and valid concerns in regards to it. You can't just play around with numbers as you wish.

the lighting network will require bigger blocks too....

According to the wallpaper it will be able to accommodate 30 million users at a 1 MB block size limit.

we simply have to do this, the only thing to discuss now is when, thats all.

When, how much and test. Not as simple as you think.

core says 1 year because they want the fee market to grow, and get poeple to come to there their second layer solution sooner rather than later.

There is no such thing as  "their" second layer solution. You could develop LN yourself, if you had the necessary skills.
Update: Removed completely false statement.

[1713923689]

1713923689

[1713923689]

1713923689

[adamstgBit]

the lighting network will require bigger blocks too....

According to the wallpaper it will be able to accommodate 30 million users at a 1 MB block size limit.

with the 1MB blocks currently all full, i seriously doubt thats true.

what happens when a payment channel with 10,000TX needs to be settled on the blockchain?

[David Rabahy]

To scale we must either;

1) have fast enough hardware
2) improve the algorithm, i.e. verify without pairing
3) verify in the background (although the verification has to happen sometime)
4) constrain the sum of sigops/transaction in a block

Can someone please provide an example of transaction that requires two or more sigops?

this is a none issue
#1 #2 is has already been done

it's not like these crazy computational intensive TX are legit, you only get into trouble if you try to allow this crazy spam like TX with thousands of inputs.

miners are allowed to orphen a block for ANY reason. I think it's perfectly valid to not allow spam TX designed to slow down validation time of the block.

1) Oh?  What speed hardware can handle what number of sigops?  With quadratic growth eventually some number of sigops will exceed the capacity of any conceivable hardware.
2) Please help me understand; I am not aware of this development yet.

So, each input comes with a sigop; I see, actually that makes perfect sense.  Hmm, would it make any sense to create a number of smaller transactions that consolidate the many inputs?  Perhaps it would be possible/better to avoid creating addresses with small amounts in the first place.  Just trying my best to understand.  I appreciate your patience and efforts.

[adamstgBit]

To scale we must either;

1) have fast enough hardware
2) improve the algorithm, i.e. verify without pairing
3) verify in the background (although the verification has to happen sometime)
4) constrain the sum of sigops/transaction in a block

Can someone please provide an example of transaction that requires two or more sigops?

this is a none issue
#1 #2 is has already been done

it's not like these crazy computational intensive TX are legit, you only get into trouble if you try to allow this crazy spam like TX with thousands of inputs.

miners are allowed to orphen a block for ANY reason. I think it's perfectly valid to not allow spam TX designed to slow down validation time of the block.

1) Oh?  What speed hardware can handle what number of sigops?  With quadratic growth eventually some number of sigops will exceed the capacity of any conceivable hardware.
2) Please help me understand; I am not aware of this development yet.

So, each input comes with a sigop; I see, actually that makes perfect sense.  Hmm, would it make any sense to create a number of smaller transactions that consolidate the many inputs?  Perhaps it would be possible/better to avoid creating addresses with small amounts in the first place.  Just trying my best to understand.  I appreciate your patience and efforts.

i dont know the details...

I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds.

[adamstgBit]

we need to get Gavin and Vladimir in the same room and ask them these questions.
I think you'll see that the reason they disagree isn't because they disagree about technical limitations but rather different visions.
One believes bitcoin full nodes need to run on a Raspberry pie the other doesn't think thats necessary.

[David Rabahy]

I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds.

Ah, I shall research these but they both sound like software to me.  Hmm, unless "HELLO!" isn't software and you were just indicating that faster hardware is just so obvious.

Certainly faster hardware is coming at us; but a quadratic growth problem will *always* out scale even the greatest conceivable hardware.

A linear improvement in the software is always appreciated but again it is *only* linear (even if it is a massive 5x) as compared to quadratic growth, i.e. n².  For example, suppose it takes t amount of time to process one sigop.  Then a transaction with n sigops will take approximately n²*t amount time.  Now we unleash the mighty libsecp256k1 5x improvement.  So, we have n²*(t/5).  When n is small this is great news.  For example, 1²*t vs. 1²*(t/5) or 1t vs. t/5 gets us the full 5x advantage but 10²*t vs. 10²*(t/5) or 100t vs. 20t is still taking 20t and not 10t let alone 2t to do those 10 sigops.  Moreover, 100 sigops works out to 10,000t vs. 2,000t; and who wants to compute 2,000t for just 100 sigops?  Honestly/sincerely I am utterly delighted at the 5x offered by libsecp256k1 but against quadratic growth it pales.

[sgbett]

Satoshi was wrong about so many things.

He was right about things too.

<snip>
Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
</snip>

[pedrog]

According to the wallpaper it will be able to accommodate 30 million users at a 1 MB block size limit.

30 million users?

[David Rabahy]

we need to get Gavin and Vladimir in the same room and ask them these questions.
I think you'll see that the reason they disagree isn't because they disagree about technical limitations but rather different visions.
One believes bitcoin full nodes need to run on a Raspberry pie the other doesn't think thats necessary.

Ah, vision; this is always worthy of lively debate.  As much as I love a deep technical dive into the underpinnings and the passions let loose, they are often misunderstood by the observers.

My personal hope is those that are able to do are doing and so not available to debate.  They will prove themselves in the only way that matters; deliver working code.

The rest of us that can't (or won't) are left to do our best at picking up the ideas of the doers and representing them as well as we can.

In my humble personal vision, I see Bitcoin being adopted very widely long before the fees climb.  But blindly cranking up the block size without constraining the impact of transactions with many sigops is taking an unwise risk.

[franky1]

everything you hear about why we shouldn't increase blocksize is a bullshit excuse to delay the inevitable.

Nope. There are true and valid concerns in regards to it. You can't just play around with numbers as you wish.

the reason they want to wait a year is not to give bitcoin more buffer space to grow and allow more ONCHAIN, they want to delay it so that they can then increase it marginally, only enough to fill the buffer space with the flags and opcode bloats that LN needs. forcing people away from onchain. and allowing the ONCHAIN fee to increase due to being nearly full. as more incentive to divert people away from bitcoins ONCHAIN.

as for the raspberry pi debate
RasPi 2. 900mhz
1gm ram

RasPi 3 1.2ghz (33% increase)
1gb ram

33% increase in processing speed in just 1 year..
say rasPi2 could handle 2000 signature verification's every couple minutes.(understatement used for basic maths)
rasPi3 can handle 2660 signature verification in the same time.

now add on libsecp256k1's 5x performance.

and a RasPi 3 can handle 13300 verification in after april 2016 that rasPi 2 could handle 2000 just a couple months ago

and to mr david rabahy, i know you do love your maths. but please dont take Lauda's word for it because he heard it from someone who heard it from someone. because thats just chinese whispers.

though i myself think the quadratic debate is a moot point because we are talking about 2mb buffer code to be added in april (not now) which will activate after quadratic doomsday scenario no longer becomes a thing. so to all intense and purposes by the time 2mb is activated the quadratic debate does not even need to be mentioned.

but i would still like to see some real maths using real bitcoin data to see if quadratic debate was even a thing during 2009-april2016

[Lauda]

30 million users?

My god, I have made a HUGE mistake (as I've said this in a few places). I've just re-read the wallpaper and my statement is completely wrong:

If we presume that a decentralized payment network exists and one person will make 3 blockchain transactions per year on average, Bitcoin will be able to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions per MB).

I must apologize. If anyone sees this mistake anywhere please notify me and I'll delete it.

I assume hardware is always getting better because HELLO! and libsecp256k1 offers 5x validation speeds.

Libsec256k1 does not have an effect on the validation problem (Gavin confirmed this somewhere on Reddit but I can't find it).

with the 1MB blocks currently all full, i seriously doubt thats true.

what happens when a payment channel with 10,000TX needs to be settled on the blockchain?

My statement is wrong (read above). However, the answer to your question is: It needs 1 transaction on-chain (to close the channel).

[David Rabahy]

Page 43 you'll find some graph. And this doc is very interesting at all (also Visa can be found in that ...)

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf

Thank you so much for the link.  I am reading through it but it is long and will take time to digest.  But honestly I will most likely tire of it and not finish; sorry.  I did find the chart on page 43 showing lines of code by developer.  Please help me understand the conclusion we are meant to derive.

[franky1]

laudas evidence is not science or technical analysys.. but an image he is advertising..

when you go to your doctor do you ask for a glossy leaflet or to ask the doctor for specific details and maybe ask for a second opinion..

lauda tried to base his whole segwit beliefs on another image from last year, and got proven wrong on multiple times.

i advise everyone to have an open mind and do your own investigations. do not follow lauda because his information is flawed. "he is a good cars salesman but he is no mechanic"

he is a good pharmacist dispensing drugs but he is no doctor

[franky1]

with the 1MB blocks currently all full, i seriously doubt thats true.

what happens when a payment channel with 10,000TX needs to be settled on the blockchain?

My statement is wrong (read above). However, the answer to your question is: It needs 1 transaction on-chain (to close the channel).

30 million users making a transaction..each.. ONCHAIN to lock their funds into LN

then 1 transaction ONCHAIN filled with 30million-60million outputs to settle the balances with the destination while also returning the 'change' to the originator meaning atleast 2 outputs. destination and origin, for every input.

now do the maths

[pedrog]

LN whitepaper is based on assumptions?

[franky1]

LN whitepaper is based on assumptions?

yep LN code for bitcoin is not really active.. otherwise we would be using it.

many coders think of best case scenarios. but hardly ever hack it.

even during 2009-2016 the coders say bitcoin works because other people cant hack it, meaning they leave it for others to find out its weaknesses and pretend everything is perfect until a weakness is found.

[David Rabahy]

as for the raspberry pi debate
RasPi 2. 900mhz
1gm ram

RasPi 3 1.2ghz (33% increase)
1gb ram

33% increase in processing speed in just 1 year..
say rasPi2 could handle 2000 signature verification's every couple minutes.(understatement used for basic maths)
rasPi3 can handle 2660 signature verification in the same time.

Wait; that doesn't take into account the quadratic growth aspect.  The correct calculation is, if rasPi2 can do 1 sigop in t and 2000²*t in a couple of minutes then rasPi3 can handle 1 sigop in 0.75t (maybe) and so in those same couple of minutes we have to solve;

X²*(0.75t) = 2000²*t
X=2309

Certainly a nice increase but not 2660.  Does sigop verification scale linearly with GHz?

[David Rabahy]

laudas evidence is not science or technical analysys.. but an image he is advertising..

Gosh, I'm pretty sure that's what we are all doing (me included).  I do try hard to get the math right but I am hand waving a lot along the way trying to impress everyone; sorry.  I do examine each and everyone's posting with a critical eye; nothing is taken as gospel as is.

[franky1]

as for the raspberry pi debate
RasPi 2. 900mhz
1gm ram

RasPi 3 1.2ghz (33% increase)
1gb ram

33% increase in processing speed in just 1 year..
say rasPi2 could handle 2000 signature verification's every couple minutes.(understatement used for basic maths)
rasPi3 can handle 2660 signature verification in the same time.

Wait; that doesn't take into account the quadratic growth aspect.  The correct calculation is, if rasPi2 can do 1 sigop in t and 2000²*t in a couple of minutes then rasPi3 can handle 1 sigop in 0.75t (maybe) and so in those same couple of minutes we have to solve;

X²*(0.75t) = 2000²*t
X=2309

Certainly a nice increase but not 2660.  Does sigop verification scale linearly with GHz?

your assumption that quadric wont be solved in april.
also if 1000 has 33% increase=1333
2000 =2666
so i was using single sig before april(i even bracketed that i understated it for simple maths) and comparing it to scaling after april using technology available in april and code changes after april which make th quadratic debate meaningless

but ultimately my maths was simplified so will leave you to do the more detailed maths

[Yakamoto]

I think that it is entirely possible for the Botcoin network to be scaled so that it can handle all the transactions that would be occurring during a normal day, but there has to be the implementation of the 2MB blocks for right now.

I'm not sure why this has to be such an argument and why it can't be scaled. As long as Bitcoin remains as decentralized as it currently is, would that not be beneficial to the network?