Topic: Satoshi Nakamoto: "Bitcoin can scale larger than the Visa Network" - page 8. (Read 18415 times)

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

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.

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?

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.

LN whitepaper is based on assumptions?

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

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

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.

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:
Libsec256k1 does not have an effect on the validation problem (Gavin confirmed this somewhere on Reddit but I can't find it).

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

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

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.

30 million users?

He was right about things too.

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.

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.

i dont know the details...

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

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.

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?

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

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

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

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.

everything you hear about why we shouldn't increase blocksize is a bullshit excuse to delay the inevitable. the lighting network will require bigger blocks too....
we simply have to do this, the only thing to discuss now is when, thats all.
core says 1 year because they want the fee market to grow, and get poeple to come to there second layer solution sooner rather than later.
they would have us keep bitcoin first layer always 1 step behind, so that the second layer solution is attractive from day 1.

if you can't see this reality then you haven't done enough digging.