Create account

replied 2199d
Bitcoin Faucet
... scale linearly. So just because we can do 33 to 65 doesn't mean that we'll go faster. If you don't parallelize the block verification how will you take advantage of multicore CPUs?
Bitcoin Faucet
replied 2199d
Maybe you should read the SV road map.
https://bitcoinsv.io/roadmap/
Q1 2019
replied 2198d
Thanks for the link. I did go through it. So SV is planning to add multithreaded verification of blocks. But it doesn't answer how you can handle a stream of 128mb blocks right now.
Bitcoin Faucet
replied 2198d
Who said anything about a stream? Blocks are produced on average every 10 minutes.
Most decent servers can process 128MB block in about 5 to 10 seconds.
replied 2193d
Also, ordering information doesn't grow linearly as the blocks increase in size. So CTOR will be an immense boon for graphene when blocks get huge.
replied 2198d
... it. But if you say that most servers can already handle it then cool. Will they be able to handle it with DSV as well btw? Is it more complex than normal sigverify or same cmplxty?
Nikamoto
replied 2198d
Interested too for dsv. I think it's the same thing but I'm not sure
replied 2193d
It should be the same complexity as normal sig verify but I guess you can put many of them in one TX. Otherwise Ryan's point about DSV being a subsidy doesn't make sense.
homopit
replied 2193d
True, it really doesn't make sense.
replied 2198d
Yeah it's a stream of blocks, one per 10min. Ideally you'd want the median server to be able to *easily* handle processing the blockchain so that people can build services on top of...
Bitcoin Faucet
replied 2198d
This network is intended for miners and merchents not people running rasberry pi's.
replied 2199d
So why didn't CSW install the "Original Bitcoin Protocol" in the last update? Shouldn't have that been the first thing they did?
Bitcoin Faucet
replied 2199d
What's in the oringal white paper thats not in SV?
replied 2199d
That's not answering the question.