Topic: Once again, what about the scalability issue? - page 4. (Read 11259 times)

Um if you could do all that well you could rip off full nodes as well.  Only the portion related to peer selection is relevant.  SPV are more vulnerable to an isolation attack.   SPV nodes should have very good peer selection algorithms.

+21000000

The thing I was referring to was not block chain compression (that's not making a big difference) but rather pruning, i.e. deleting of old data from disk. There has been no progress on that front. Sipa worked on other things instead.

If your problem is you can't afford to even download 10G of data then you're better off using an SPV client instead. I'm pretty sure almost any VPS could run bitcoind - where did you find a VPS that has <20G of disk and bandwidth? If you ran one on a VPS you could use an SPV client locally that connects to it, and that'd be an equivalent security level.

The world will move to off blockchain wallets and sites like inputs.io

Wonder no more;  I build both from source code and released distributions along with organized and auditable patches.  I've done things this way since I started using FreeBSD in the 90's.

When I run bitcoind these days I run a build which includes a compilation of openssl, boost, and berkeleydb and I can select the source distribution and apply any patches I like along the way.  Further, I can re-build with any code tweeks to any of these items in a matter of minutes and have a new binary running seconds after that.

Actually, I don't run bitcoind currently.  I'm behind a satellite system and the block chain is twice the size of my total monthly download allotment (for which I pay $80/mo.)  Just the other day I was looking around for a VPS but unfortunately the block chain itself is starting to exceed the size that low tier VPS's support.

Speaking of, any news on the block chain compression front as mentioned in the whitepaper?  That was kind of a selling point to me (recognizing immediately the potential scaling issue.)  Last I heard (from you IIRC) ~sipa was trying to have a life and working on it sporadically.

If the transaction rate doesn't ramp up soonish to levels far beyond what a 1 MB block can support the network will be in trouble. ASIC companies are pumping out more hashing power every day but the miners are all competing for the same ~25 BTC / block. Unless the exchange rate ramps up as fast as the difficulty, 25 BTC/block won't be able to economically support the mining infrastructure for very long. Then you'll see a huge overshoot effect where a lot of miners drop out and leave the network vulnerable, or even worse, sell off their now-unprofitable ASICs to someone who uses them to attack the network.

The block reward needs to grow, and the only way that happens is via transaction fees, and the only way to get significant amounts of transaction fees is to process lots of transactions.

I was able to compile OpenJDK8 on MacOS X a few weeks ago, at least. But there are other JVMs that are not as fast, which are also open source. Where do you get your compiler and operating system binaries from, I wonder?


At the time we had these conversations I didn't know he would disappear. That thread is from the end of 2010. I think it's still worth quoting him on this especially when people assign more meaning to design decisions than can really be justified. Unfortunately GMX doesn't (or didn't back then) use DKIM so I have no signatures or any other proof, but anyway it shouldn't matter, it's obvious from things he posted earlier that there wasn't intended to be any hard/small limits on volume.

I actually don't think I was around when Satoshi put the 1mb limit in place. I played with Bitcoin back in early 2009 but nobody used it so I lost interest and came back later. Back then he routinely made big or hard forking changes to the protocol in giant commits that mixed many changes together and had no useful descriptions. It was still his personal toy/prototype thing, so he got away with things we wouldn't be able to do today.

Indeed.

Users have to understand that SPV does rely on a quorum of trusted third parties, specifically miners, which makes it significantly less secure. For instance I could temporarily take over a large amount of hashing power by hacking a large pool and I can use that to profitably rip off your business and many others with fake confirmations. If I manage to hack >50% of hashing power - which would require nothing more than hacking into about 3 pools right now - I don't even need to isolate your SPV node from the network. (which is also easy because SPV nodes have to trust their peers) I may even do it just to push the price of Bitcoin down and profit from shorting it, or I may have other more nefarious motives.

Similarly MultiBit and other SPV wallets provide no protection against fraudulent inflation yet, and the architecture they encourage puts the censorship of transactions in the hands of a very few.

I guess you are addressing me since I was the only poster in the recent activity of this thread.  Can you point out the 'incorrect information' I supposedly spread?


Alas, Java VM joins Windows and Android as systems I stay away from for security work.  It at least has been possible at some point to compile the JVM myself but it's a hassle and never worked right on my system.  I trust almost no pre-complied systems from large companies (especially Oracle) and that had been the case since before PRISM was disclosed.  But is even more so now.


It would not be the first time that someone fucked up and accidentally did the right thing.  My point is that no matter what the size, it is useful to bump into it and let the economics of transaction fees work for a while to find out empirically how the system functions.  This will allow certain systems to build up around the expectation of a more realistic mode of self sufficiency.

I think it pretty fair to say the 'satoshi' also elaborated on an end-point of the system being supported by transaction fees.  As opposed to, say, users being milked for the PII intelligence value they provide (as has become a reality for e-mail and www protocols.)  'satoshi' may very well have anticipated and welcomed this eventuality and you would know better than I, but I will say that if so he fucked up by making it a hard-fork to adjust the system to this trajectory.

Put another way, I don't think that someone 'supports' the kind of system I would like to see Bitcoin become by being exploited in the same manner that web service users are under many other protocols.


I am not doubting the veracity of your private e-mails with 'satoshi', and don't doubt that you flipped out when you saw the 'quick hack' (sans commit comments) and provoked this note, but there is an amusing parallel here between how everything the NSA does is legal due to secret laws which nobody else can see.  There is also a similarly amusing parallel between Jesus vanishing only being accessible to persons with special communications powers.  Again, I don't doubt that you posses such powers...it's more 'satoshi's divinity which I find debatable.

 - Edit in:  A hypothesis which also strikes me as possible is that 'satoshi' has been to some extent 'using' you (Mike).  I mean you have fearsome technical skills and drive, and also a positioning within the industry which has value of various sorts.  Your participation could be leveraged effectively by some management of the possible points of discontinuity on the evolution and endpoint of the Bitcoin system.

Could someone please explain to me why this matters again?

Right, right, I get that the number of transactions is increasing but does this, again, just boil down to "It takes new people for ever to download the block chain"?

I just don't see how a 10G blockchain isn't scalable when most people run 1TB+ disks.

Or a bit closer, read my stickied thread in this very forum:

https://bitcointalksearch.org/topic/block-chain-sizestorage-and-slow-downloads-for-new-users-252937

Yes, IIUC.

Thx. Does MultiBit use this approach?

See parts 7 and 8 of Satoshi's whitepaper:
http://bitcoin.org/bitcoin.pdf

Who provides data for that and how did you make sure that this blockchain is legit (has the highest cumulative difficulty)?

I don't know how it works, but you can probably make a php script to check blockchain.info and how much btc have every address / how much confirmations have a transaction and so on.
Like all btc websites (dices, mcxNOW, ...)

I ought to admit that I know almost nothing about MultiBit. Could you explain how it's possible to verify a transaction if you don't have a whole blockchain? You have to check the chain of ownership till you meet the block the coins were generated in. AND you have to check that none of the satoshis from these coins were double-spent.

Can we stop spreading incorrect information please?

MultiBit does not rely on a trusted third party. That's the point of it - it reads the block chain.

Satoshi put a 1mb block size limit in place to avoid people creating giant "troll blocks" early on when mining was easy. It was a part of a series of quick anti-DoS hacks he put in, and he talked about removing the limit when the software scaled better. Indeed he talked about Bitcoin scaling to VISA-size transaction loads right from the start of the project. 1mb wasn't some super meaningful design choice he made in order to achieve some particular economic outcome.

In fact, here's a quote from an email he sent me on the matter back in 2010:


We actually do have client-only implementations these days, which is why Gavin and I have been arguing to increase the block size. It isn't as important as it once was.

Actually, the thread had been pretty quite until you piped up.

For my part, I'm still waiting for a good read on the economics of transaction fees.

Growth at 7 TPS or there abouts is eminently manageable while retaining a realistic P2P structure (possibly part of the reason Satoshi chose it?)  Even notably higher transaction rates would be manageable and probably defensible in case of most significant forms of attack, but the key is that things have to be predictable in order to facilitate good engineering and planning for those who have an interest in trying to help support the system.

Blockchain size has crossed 10000 MB mark. I think it's time to close this thread until we see 20000 MB...