Cryptocurrency: Scaling, Privacy [re: on whatever...]

[Punk-Stasi 2.0]

On Sun, 15 Dec 2019 05:51:44 -0500
grarpamp <grarpamp at gmail.com> wrote:

> On 12/14/19, Punk-Stasi 2.0 <punks at tfwno.gf> wrote:
> > 	haha - arbitrarily...
> 
> BTC is arbitrarily choking down their blocksize, haha


	"arbitrary" means "for no reason" but there's a painfully obvious reason to limit the size/rate of growth of so called blockchains. You can argue that a particular value for the limit is arbitrary, which is technically correct...yet irrelevant. 

> is that it will still grow unbounded, then there is...
> youtube: lightning network sucks

	you expect me to do your side of the arguing for you? You're not even bothering to link your own shills? =)

	But OK, I don't mind admiting that the LN is less than ideal or that it 'sucks'. Then guess what? Cryptocurrencies suck. Blockchains are 'transparent' by default and don't scale. And if you obfuscate them, then they scale even less! And second layer solutions have their own set of problems. 

> search: corporation problems

	you might want to be somewhat more specific...


> A few more good innovations by some other coins, from
> better groups, a transfer of faith... and BTC is done in.

	haha yes. If somebody solves problems that no one has solved yet then..yes, those problems won't be problems anymore.


> 
> Regardless, coins are really hard to do right,
> and it's probably still too early to know for
> sure what right is likely to end up looking like.
> 
> > 100mbytes blocks.
> 
> that's 100MB... every 10min = 167kbps, no problem.


	that's 1.66 megabits per second. And I assume that among  people who *have* internet access, 1mbit connections are still common. 


> And if it was problem, light clients query out spv-like
> services, could add in a sizable dht cloud too.

	yes, the GCHQ-rothschild cloud. Go for it.


> 
> > 	Current size of bitcoin's blockchain is 270gbytes. Downloading and
> > processing that amount of data is not trivial. Only some people in the so
> > called 'developed' world can do it.
> 
> Every house does not have a well, nor LAN, they
> pool together to build and share, cafe coop, etc then
> won't even have to wait 25 days at a lowly 1Mbps.

> Every house does not have a well

	sidenote : every house SHOULD have a well instead of being connected to govcorp's water supply. 

	Now, what was the point of "PEER TO PEER electronic cash"?


> 
> > 	Now, what if blocks are a hundred times bigger? In that case you get 5
> > terabytes PER YEAR.
> 
> It has already been suggested that storing entire blockchains, certainly
> for any sole function pure currency chain, since their genesis...
> is a legacy first gen tech thought, and quite silly idea to keep doing.


	yeah, so what's the 'next generation' solution? 


> a) they can be sharded signed and distributed out to query trees,
> doesn't solve things long term.
> b) utxo can be flag cutover coinbase input to empty chain, very unlikely.
> c) chain protocols will evolve to effectively consensus mine
> a utxo database, hashed checkpoint series, etc thereby
> allowing tx's and blocks to be thrown away after the series
> becomes too confirmed and locked to mine a different one.
> 
> Storage becomes mooted, 


	The problem isn't storage per se. The thing is, all peers have to validate all transactions. And that may include all past transactions. It may seem pointless to revalidate old transactions but how do you arrive at the current state if you don't? 


> the lingering limitation seems
> to be estimating bandwidth the processing participants
> need.

	I don't know. The problem is that 'peers' need to audit the whole system. And that takes resources. So peers start 'delegating' powers because that's more 'efficient', and we end up with the same central tyranny we have now.



> 
> > data center
> 
> Certainly not under todays models of a few fake audited centralized
> closed corrupt wannabe govbankster crypto corporations.


	well that's the only kind of datacenter that has ever existed. 


> Under a well distributed standardized 24x365 walk in publicly
> auditable opensource etc etc... maybe. And even that should
> be tried to be designed out if at all possible.